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ABSTRACT 


The  purpose  of  this  thesis  is  to  communicate  a  general 
knowledge  of  software  engineering  principles  that  can  be 
applied  to  the  development  of  a  software  system.  Fundamental 
Software  Engineering  concepts  are  first  discussed  and  then 
applied  to  a  personnel  database  management  system  which  is 
featured  throughout  the  thesis.  The  individual  tools  and 
techniques  that  are  used  in  each  phase  of  the  system  develop¬ 
ment  are  widely  known  in  the  computer  science  community  and 
each  has  been  employed  successfully  in  certain  situations. 
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During  the  past  thirty  years  the  advances  in  computer 
hardware  have  been  so  phenomenal  that  even  the  pioneers  in  the 
computing  industry  are  amazed  at  how  much  progress  has  been 
made.  Progress  in  computer  hardware  with  respect  to  cost, 
speed  of  computations  and  decrease  in  size  is  measured  by 
several  orders  of  magnitude  and  the  most  amazing  is  the  forty 
percent  compound  annual  rate  of  reduction  in  the  unit  cost  of 
memory  and  storage. 

Unfortunately,  our  ability  to  build  software,  which  is 
necessary  to  interface  with  the  computer  hardware,  has  not 
progressed  as  rapidly.  As  the  range  of  computer  applications 
has  grown  and  the  complexity  of  tasks  computers  can  handle  has 
increased,  the  cost  of  developing  software  for  a  computer 
system  has  increased  so  much  that  it  has  become  by  far  the 
most  costly  component  in  the  system.  The  main  cause  of  the 
increase  in  the  cost  of  software  was  that  the  existing  metho¬ 
dologies  for  software  development  were  inadequate.  As  a  result, 
many  software  systems  failed,  and  many  others  were  late, 
unreliable,  difficult  to  maintain,  their  performance  was  poor 
and  they  cost  much  more  than  originally  predicted. 

Much  research  has  been  conducted  during  the  last  twenty 
years  on  software  development  techniques  and  methodologies 
that  would  end  the  "software  crisis".  A  new  technological 
discipline,  Software  Engineering,  has  been  developed  to 
improve  the  quality  of  software  products  and  to  increase  the 
productivity  of  software  engineers. 

The  term  "Software  Engineering"  was  chosen  as  the  title  of 
a  NATO  conference  in  1968  in  order  to  express  "the  need  for 


software  manufacture  to  be  based  on  the  types  of  theoretical 
foundations  and  practical  disciplines  that  are  traditional  in 
the  established  branches  of  engineering".  [Ref.  1:  p.  13] 
Since  then  a  lot  of  activity  has  been  focused  on  software 
engineering.  The  Institute  of  Electrical  and  Electronics  Engi¬ 
neers  (IEEE)  has  been  publishing  the  "Transactions  on  Software 
Engineering"  since  1975.  The  Association  for  Computing 
Machinery  (ACM)  has  founded  a  Special  Interest  Group  on  Soft¬ 
ware  Engineering  (SIGSOFT).  Several  conferences  and  symposia 
on  this  new  discipline  have  been  sponsored  by  many  organizati¬ 
ons.  The  chairman  of  the  IEEE  Richard  Fairley  stated  in  1979 
that  "Software  engineering  has  evolved  into  a  major  subdisci¬ 
pline  of  computer  science  and  engineering.  Although  much 
remains  to  be  done,  a  body  of  knowledge  and  a  set  of  guide¬ 
lines  have  emerged  which  incorporate  traditional  engineering 
values  into  the  production  and  maintainance  of  software 
systems".  [Ref.  2]  During  recent  years  a  great  number  of 
well  known  and  unknown  computer  scientists  and  theorists  have 
defined  numerous  techniques  and  methodologies  on  the  develop¬ 
ment  of  software  products.  Much  discussion  and  controversy 
follow  the  announcement  of  every  new  method  or  technique.  Some 
of  these  techniques  are  more  controversial  than  others.  Some 
of  them  do  not  work  at  all  in  certain  situations  while  they 
are  very  effective  in  others.  Some  techniques  are  very  promis¬ 
sing;  Ed  Yourdon,  in  one  of  his  many  books  on  the  structured 
techniques,  trying  to  convince  the  reader  how  good  these  tech¬ 
niques  are,  he  writes:  "...  what  the  techniques  can  do  is 
impressive.  Chances  are  that  if  you  use  the  techniques,  you'll 
be  sipping  your  mint  julep  in  your  Mediterranean  villa  before 
long.  If  you  don't  use  the  techniques,  well,  chances  are 
you'll  be  replaced  by  someone  who  does."  [Ref.  3:p.  3] 
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After  so  many  years  of  analyzing  and  studying  the  mecha¬ 
nisms  of  software  development,  software  engineering  has  not 
yet  been  able  to  develop  a  universally  accepted  methodology 
for  building  software,  and  software  development  is. still  con¬ 
sidered  an  art  by  most  people.  The  truth  is  that  many  of  the 
developed  techniques  really  work.  Studies  conducted  by  large 
software  organizations  have  proven  that  the  programmer  produ¬ 
ctivity  and  the  software  quality  has  improved  significantly 
with  the  use  of  certain  techniques.  For  example,  IBM  studies 
report  an  average  of  forty  percent  productivity  savings  in 

real -  time ,  business  and  systems  software  projects  utilizing 
structured  programming.  [ Ref .  4]  In  other  projects,  however, 
it  has  been  found  that  the  principles  of  software  engineering 
do  not  always  guarantee  success. 

Although  a  definite  trend  exists  in  academic  computer 
science  circles  toward  the  recognition  of  software  development 
as  an  engineering  discipline,  such  recognition  is  much  less 
pronounced  among  software  houses  and  other  software  producers. 
One  of  the  reasons  is  that  the  established  software  enginee¬ 
ring  principles  and  techniques  are  very  often  too  technical 
and  require  a  higher — level  of  knowledge  in  Computer  Science  to 
understand  them.  Unfortunately,  the  main  body  of  programmers 
consists  of  people  with  litle  or  no  higher  education  back¬ 
ground.  In  fact  only  a  very  small  fraction  of  the  people  who 
are  programming  computers  have  ever  studied  computer  science 
in  any  depth.  In  the  U.S.A.,  some  29,600  bachelor's  degrees 
were  awarded  in  computer  and  information  sciences  in  the  six- 
year  period  1972-1977.  [Ref.  5:  Pg .  169]  These  courses  of 
study  were  first  offered  in  the  1960’s  and  are  still  growing; 
therefore  it  can  be  assumed  that  a  comparable  number  of  degrees 
were  awarded  in  the  years  before  1972.  Although  we  do  not  have 


the  statistics  for  the  years  after  1979  it  is  estimated  that 
the  total  number  does  not  exceed  one  hundred  thousand.  This 
number  is  quite  small  in  comparison  with  the  300,000  program¬ 
mers  working  full  time  and  another  300,000  who  work  part  time. 
[Ref.  6:  Pg .  6]  On  the  other  hand,  the  existing  literature  on 
software  engineering  is  anything  but  reliable.  The  books  one 
can  find  on  software  development  tools  and  techniques  are 
usually  very  abstract  and  difficult  to  read.  The  majority  of 
such  books  concentrate  on  only  one  phase  in  the  software  life- 
cycle  and  provide  no  int*  rface  with  the  rest  of  the  phases. 
Most  of  them  do  not  provide  a  case  study  to  illustrate  the 
theoretical  part  and  those  who  do,  usually  give  very  simpli¬ 
fied  examples  that  have  nothing  to  do  with  the  complexity  of 
the  real  world  and  they  also  shift,  to  a  different  case  study 
as  they  go  from  one  phase  to  another.  As  a  result  of  the  above 
situation  the  books  on  software  engineering  concepts  have  a 
very  small  number  of  readers,  limited  tc  academians  and  compu¬ 
ter  science  students  in  the  universities.  On  the  other  hand, 
books  of  the  type  "How  to  become  a  programmer  in  ten  easy 
steps'  or  books  with  applications  software  that  can  be  extended 
or  modified  to  fit  someone's  needs  are  becoming  best  sellers. 

The  purpose  of  this  thesis  is  to  communicate  a  general 
knowledge  of  software  engineering  principles  that  can  be 
applied  to  the  development  of  a  software  system.  A  personnel 
database  management  system  was  chosen  to  serve  as  an  example 
throughout  the  thesis.  The  individual  tools  and  techniques 
that  are  used  in  each  phase  of  the  system  development  are 
widely  known  in  the  computer  science  community  and  each  has 
been  employed  successfully  in  certain  situations.  This  does 
not  mean  that  the  presented  techniques  are  the  only  techniques 
a  software  engineer  can  use.  On  the  contrary  there  are  as  good 


or  even  better  techniques  in  certain  cases.  What  the  reader 
must  understand  is  two  things: 

a.  The  development  of  any  software  system  must  follow 
certain  steps.  Different  people  have  given  different  names  to 
these  steps  and  others  have  combined  or  analyzed  them.  Whether 
the  six-step  decomposition  of  a  system's  life-cycle  followed 
in  this  thesis  is  better  than  others  is  not  a  key  issue.  What 
is  important  is  to  recognize  that  phases  exist  and  organize 
the  approach  to  account  for  them. 

b.  The  development  of  software  systems  can  be  fascilitated 
by  software  engineering  tools  and  techniques  that  allow  the 
developer  to  continuously  assess  the  extend  of  his  progress 
and  the  validity  of  his  decisions.  The  tools  and  techniques 
used  in  the  development  of  the  example  software  system  are  not 
to  be  considered  as  the  most  recommended  ones  or  as  suitable 
for  all  cases.  Each  software  engineer  may  choose  the  set  of 
tools  and  techniques  that  he  thinks  is  most  appropriate  for 
the  system  he  is  developing.  The  idea  is  that  such  sets  do 
exist  and  the  thesis  provides  such  an  example. 

The  reason  why  a  database  management  system  (DBMS)  was 
selected  to  serve  as  a  case  study  in  the  thesis  is  that  a  DBMS 
is  like  any  other  software  system,  only  it  is  sorewhat  more 
complicated  because  it  involves  the  design  of  a  database.  An 
additional  reason  is  that  DBMS's  are  very  popular  today  and  it 
is  likely  that  most  software  engineers  will  face  the  problem 
of  developing  such  a  software  system. 
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1 1 .  THE  SOFTWARE  DEVELOPMENT  PROCESS 

To  better  control  the  development  of  a  software  system, 
software  engineering  has  identified  a  sequence  of  stages 
through  which  the  system  passes;  these  stages  are  collectively 
called  the  software  development  life-cycle.  The  stages  of  the 
software  life-cycle  followed  in  this  thesis  are  described 
be  1 ow . 

A.  PROBLEM  DEFINITION 

This  first  stage  helps  the  software  engineer  understand 
the  problem  and  define  the  objectives  and  the  scope  of  the 
system  he  will  develop. 

B.  FEASIBILITY  STUDY 

During  this  stage  it  is  determined  if  the  problem  can  be 
solved  and  a  number  of  solutions  that  might  satisfy  the  user's 
needs  within  the  defined  scope  are  identified.  At  the  end  of 
this  stage  the  software  engineer  obtains  a  decision  from  the 
user  or  management  whether  to  proceed  with  the  development  of 
the  system. 

C.  ANALYSIS 

This  is  the  most  important  stage  in  the  system  life-cycle. 
The  software  requirements  (i.e.,  the  system's  functions  and 
operational  constraints)  are  specified  and  documented  during 
ana  1 ysi s . 

D.  SYSTEM  DtSIGN 

The  software  engineer  determines  how  in  general  the  system 
will  be  implemented  by  identifying  different  alternative 
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strategies  and  selecting  the  one  that  best  satisfies  the 
system's  needs. 

E.  DETAILED  DESIGN 

The  designer  takes  the  software  requirements  prepared 
during  analysis  and  based  on  the  decision  made  during  system 
design,  organizes  them  in  a  way,  suitable  for  computer  execu¬ 
tion. 

F.  IMPLEMENTATION 

In  this  stage  results  produced  during  the  detailed  design 
are  implemented  in  source  code.  It  is  also  the  purpose  of  this 
stage  to  verify  that  this  source  code  implements  correctly  the 
design  spec i f ica t ions . 

There  is  no  single  decomposition  of  the  software  develop¬ 
ment  process.  The  one  presented  here  works  in  practice  but 
modifications  may  be  required  for  other  applications.  The 
important  thing  is  that  all  the  different  decompositions  of 
the  system  life-cycle  that  exist  require  all  of  the  above 
functions  to  be  performed,  no  matter  what  name  they  assign  to 
each  stage,  whether  they  combine  two  or  more  stages  in  one,  or 
further  decompose  one  stage. 

The  following  six  chapters  of  the  thesis  develop  each 
stage  of  the  software  development  process.  Each  chapter  is 
divided  into  two  parts.  In  the  first  part  the  theory  of  the 
particular  stage  is  given  and  in  the  second  part  this  theory 
is  applied  to  a  real  database  management  system  for  implemen¬ 
tation  in  the  Greek  Army. 
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III.  PROBLEM  DEFINITION 


The  first  step  in  the  system  life-cycle  is  the  Problem 
Definition  during  which  the  analyst  understands  the  problem 
and  defines  the  objectives  and  the  scope  of  a  system  that 
solves  it. 

A .  THEORY 

It  is  very  unlikely  that  an  analyst  would  be  asked  to  de¬ 
sign  a  system  that  has  no  precedent.  Most  of  the  time  a  system 
that  works  already  exists  but  which  may  have  some  problems  in 
its  performance.  These  problems  may  be  recognized  by  the  user 
himself  or  by  the  management.  If  the  problem  is  serious  and 
its  solution  is  considered  imperative,  then  an  analyst  will  be 
asked  to  offer  his  services. 

The  first  thing  the  analyst  must  do,  in  any  case,  is  to 
understand  the  existing  problem  and  prepare  a  written  state¬ 
ment  of  his  understanding.  Many  analysts  consider  this  step 
as  needless,  but  it  has  been  proven  that  in  a  number  of  cases 
the  delivered  system  solved  a  different  problem  from  the  one 
the  user  had  in  mind,  just  because  the  analyst  ignored  this 
step . 

B.  IMPLEMENTATION 

1 .  The  Greek  Army 

Before  introducing  the  problem  that  we  as  analysts 
will  be  asked  to  analyze  and  try  to  solve,  a  very  brief  over¬ 
view  of  the  Greek  Army  structure  and  the  soldier  life-cycle 
will  be  presented. 

The  Greek  Army  consists  of  the  Operational  Arms 
(Infantry,  Artillery,  Armor,  Corps  of  Engineers  and  Signal 
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Corps)  and  the  Support  Services.  The  Arms  and  Services  are 
manned  by  officers,  non-commissioned  officers  and  soldiers. 
The  officers  and  NCOs  are  for  the  most  part  professional 
career  personnel  who  graduate  from  the  Military  Academy  and 
the  NCO  School.  The  soldiers  are  citizens  who  have  been  con¬ 
scripted  to  serve  in  the  Army  for  a  period  of  22  months. 
Every  two  months  a  new  group  of  soldiers  is  conscripted. 
Every  Greek  citizen  has  to  join  the  Army,  usually  at  the  age 
of  21,  unless  he  has  been  medically  proven  to  be  physically  or 
mentally  incapable. 

Every  soldier  passes  through  the  following  stages 
during  his  time  in  the  military: 

-  Enlistment 

-  Basic  Training,  lasting  two  months 

-  Specialty  Training,  the  duration  of  which  varies 
depending  on  the  specialty  the  soldier  has  been  assigned. 

-  Service  in  one  or  more  of  the  units  of  the  Arm  or  Service 
to  which  the  soldier  belongs. 

-  Separation  from  military  service. 

Each  Arms  or  Service  Directorate  has  its  own  Personnel 
Office,  located  in  the  General  Staff,  which  manages  its  per¬ 
sonnel  and  is  responsible  for  the  smooth  transition  of  its 
soldiers  from  one  stage  to  the  next. 

2 .  The  Problem  Environment 

The  Personnel  Office  of  the  Signal  Corps  Directorate, 
among  its  other  responsibilities,  performs  the  following  fun¬ 
ctions  related  to  the  management  of  its  soldiers: 

-  Maintains  updated  files  of  the  soldiers  in  the 
Signal  Corps. 

-  Maintains  updated  files  of  the  Signal  Corps  Units. 
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Estimates  the  number  of  soldiers  that  must  be  trained  in 


each  special ty . 

-  Performs  the  assignments  of  the  soldiers  that  are  necessa¬ 
ry  to  fill  the  vacancies  created  by  the  retirement  or 
transfer  of  other  soldiers. 

The  personnel  responsible  for  carrying  out  the  above 
procedures  consists  of  one  captain,  2  sergeants  and  3  soldiers 
acting  under  the  supervision  of  a  colonel  who  is  the  director 
of  the  Personnel  Office.  The  director,  after  almost  2  years  of 
supervising  the  Personnel  Office,  has  come  to  the  conclusion 
that  there  are  problems  in  its  performance. 

One  of  the  problems  is  that  too  often  the  personnel 
office  is  not  able  to  prepare  the  list  of  the  soldiers'  trans¬ 
fers  and  assignments  on  time.  This  is  due  to  the  great  volume 
of  transactions  involved  and  frequently  because  of  the  untime¬ 
ly  arrival  of  the  required  information  from  other  subordinate 
units.  At  other  times,  errors  have  been  discovered  in  some  of 
the  lists  and  reports  generated  by  the  Personnel  Office. 
Finally,  the  most  important  problem  is  that  during  the  schedu¬ 
ling  of  the  soldiers'  assignments,  the  office  personnel  evalu¬ 
ate  the  needs  of  the  military  units,  but  are  rarely  able  to 
evaluate  the  soldiers  needs  as  well. 

The  Colonel  reported  his  observations  to  the  Signal 
Corps  Director  and  suggested  that  the  personnel  system  should 
be  studied  to  find  the  means  to  eliminate  the  problems.  He 
also  suggested  that  simply  to  increase  the  personnel  in  his 
office  should  not  be  considered  as  a  solution,  since  this 
would  only  create  more  problems  in  other  areas. 

The  Signal  Corps  Director  understood  the  importance 
of  the  reported  problems  and  asked  the  Studies  Directorate  to 
assign  a  systems  analyst  to  investigate  a  possible  solution. 
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3 .  The  Problem  Definition 

First  the  analyst  must  understand  the  problem.  Next  he 
must  define  the  objectives  of  a  new  system  that  would  solve 
the  problem.  He  must  also  estimate  an  approximate  cost  of  the 
new  system.  He  finally  prepares  a  written  statement  of  the 
scope  and  objectives. 

Usually  the  most  difficult  part  in  this  procedure  is 
to  estimate  the  cost  of  the  new  system.  At  such  an  early  stage 
we  do  not  usually  expect  someone  to  define  accurately  the  cost 
of  a  system,  but  to  set  an  upper  limit.  How  can  such  a  limit 
be  estimated?  The  operating  cost  of  the  existing  system  must 
be  considered  first.  The  system  is  manual,  therefore  its  main 
cost  is  the  wages  of  the  employees.  This  cost  is  calculated  to 
be  approximately  $50,000  annually.  One  of  the  constraints  for 
the  new  system  was  that  it  should  not  increase  the  personnel. 
This  means  that  the  new  system  may  be  less  expensive  than  the 
old  one  because  it  may  require  fewer  people.  Of  course  there 
is  no  way  that  the  system  could  operate  without  any  people  at 
all,  but  the  analyst  feels  that  it  could  use  two  fewer  people 
than  the  old  one,  i.e.,  a  sergeant  and  a  soldier  could  be 
transferred  to  another  office  resulting  in  annual  savings  of 
about  $10,000.  Therefore  with  a  new  system  that  costs  $20,000 
we  could  have  a  return  on  investement  in  about  two  years.  This 
sounds  like  a  reasonable  upper  limit.  In  a  few  cases  of  course 
the  management  might  agree  for  political  reasons  to  spend  even 
more  on  a  new  system  than  it  was  spending  on  the  old  one.  Our 
case  belongs  to  this  category.  The  new  system  will  satisfy  the 
soldiers  needs  for  transfers  and  this  will  have  a  positive 
effect  on  the  soldiers'  morale.  We  cannot  evaluate  morale  in 
terms  of  money.  For  the  sake  of  generality  the  systems  scope 
will  be  defined  at  $20,000. 
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Next  the  analyst  prepares  a  written  statement  of  the 
scope  and  objectives  which  summarizes  his  understanding  of  the 
problem  (see  Fig.  3.1). 


STATEMENT  OF  SCOPE  AND  OBJECTIVES 

DATE  :  29  January  1987 

THE  PROJECT  :  PERSONNEL  MANAGEMENT 

PROJECT  OBJECTIVES  :  To  investigate  the  potential  for  a 
new  system  to  perform  the  functions  of  SCD/ 
Personnel  Of f ice/Soldier  Section.  This  sys¬ 
tem  compared  to  the  existing  one  should  be: 
.  More  accurate 
.  More  timely 
.  Less  error  prone 

.  Will  consider  not  only  the  military  units 
needs  but  the  soldiers  needs  as  well. 

KEY  SELECTION  CRITERIA  :  The  number  of  employees  must  not 

increase . 

PROJECT  SCOPE  :  The  preliminary  cost  estimate  of  the  sys¬ 
tem  is  420,000  with  a  precision  of  307.  . 

FEASIBILITY  STUDY  :  In  order  to  investigate  the  potenti¬ 
al  for  this  project  more  fully,  a  fea¬ 
sibility  study  lasting  approx imate 1 y 
2  weeks  is  recommended.  The  cost  of 
this  study  will  not  exceed  41,000  and 
is  included  in  the  project  scope. 


Fig.  3.1.  The  Statement  of  Scope  and  Objectives. 
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IV.  FEASIBILITY  STUDY 


A .  THEORY 

1 .  Why  a  Feasibility  Study? 

The  initial  phase  of  the  Specification  Stage  ended 
with  the  preparation  of  a  written  statement  of  the  system's 
scope  and  objectives.  What  must  be  the  next  step? 

Many  analysts  tend  to  become  attached  to  the  first 
possible  solution  they  think  of  and  start  proceeding  in  this 
direction.  This  is  a  very  bad  habit  that  quite  often  leads  to 
catastrophic  results.  If  during  the  process  this  solution  is 
found  to  be  infeasible  then  a  large  amount  of  time  and  effort 
has  been  wasted.  Even  worse  is  the  case  when  the  analyst  does 
not  want  to  accept  that  he  failed  and  tries  to  integrate  the 
system,  changing  part  or  all  of  its  functions,  so  that  they 
fit  into  the  one  designed.  As  a  result  of  the  above  tendancy, 
many  systems  have  been  delivered  with  excessive  delays,  over 
budget  and  often  without  solving  the  problem.  In  order  to 
avoid  these  undesirable  effects,  a  feasibility  study  must 
always  follow  the  problem  definition. 

The  primary  objectives  of  a  feasibility  study  are  to 
determine  if  the  problem  can  be  solved  and  to  recommend  a  solu¬ 
tion  strategy.  There  is  no  standard  format  for  a  feasibility 
study.  Many  people  have  described  a  number  of  ways  on  how  to 
conduct  such  a  study.  The  reader  can  find  some  of  them  in 
[Ref.  7],  [Ref.  B],  [Ref.  9]  and  [Ref.  10].  There  are  many 
differences  in  the  methods  and  steps  they  follow  and  even  in 
the  contents  of  the  study.  The  method  described  in  [Ref.  10]  is 
one  of  the  most  complete  and  easiest  to  follow  and  therefore 
will  be  used  as  a  reference  point  for  the  feasibility  study. 
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The  main  steps  of  a  feasibility  study  are: 

-  Confirm  the  problem  definition. 

-  Study  the  existing  system. 

-  Develop  a  high-level  logical  model. 

-  Confirm  the  logical  model. 

-  Develop  and  evaluate  alternative  solutions. 

-  Select  one  alternative. 

-  Prepare  a  development  plan. 

-  Write  and  present  the  feasibility  study. 

A  brief  discussion  on  each  of  these  steps  follows. 

2 .  Confirm  the  problem  definition 

It  is  very  probable  that  the  analyst's  understanding 
of  the  problem  as  described  in  the  problem  definition  is  not 
quite  accurate.  For  this  reason  the  analyst  must  contact  the 
user  and  the  management  and  confirm  that  what  he  has  in  mind 
is  exactly  what  they  want. 

3 .  Study  the  existing  system 

A  new  system  almost  always  replaces  an  existing  one. 
We  usually  want  the  new  system  to  perform  basically  the  same 
functions  as  the  old  system  but  in  a  faster,  more  reliable, 
cheaper  or  generally  more  enhanced  way.  Sometimes  it  is 
desirable  that  the  new  system  includes  a  few  new  functions 
that  the  old  system  did  not  perform  or  to  eliminate  some 
functions  that  are  no  longer  needed.  In  any  case  most  of  the 
functions  in  both  systems  overlap.  Therefore,  the  study  and 
documentation  of  the  existing  system  can  provide  information 
that  will  be  very  useful  in  the  following  steps.  It  is  not 
always  easy  to  understand  an  existing  system.  During  this  step 
of  the  feasibility  study  the  analyst  must  identify  and  inter — 
view  key  people  in  the  existing  system  and  collect  documents, 
distribution  lists,  or  reports  produced  by  the  system.  It  is 
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usually  easier  to  study  an  automated  system  than  a  manual  one 
because  the  documentation  is  better  organized.  Sometimes  it  is 
helpful  to  summarize  the  gained  knowledge  in  a  systems  flow¬ 
chart.  In  any  case  the  analyst  must  keep  in  mind  that  he  is 
not  asked  to  document  the  existing  system  in  detail,  but  only 
to  understand  it. 

4 •  Develop  a  high  level  model 

The  next  step  is  to  develop  a  logical  model  that 
stresses  the  functions  that  must  be  performed  by  the  new 
system  without  considering  the  specific  physical  way  these 
functions  are  implemented  in  the  existing  system.  In  other 
words  this  model  will  represent  the  existing  system  as  it 
ought  to  be  rather  than  as  it  actually  is. 

One  of  the  techniques  that  is  often  used  to  develop 
a  high-level  logical  model  of  a  system  is  the  Data  Flow 
Diagram  ( DFD ) . 

5 .  Confirm  the  logical  model 

In  some  cases  the  new  and  the  old  systems  are  perfor — 
ming  exactly  the  same  functions.  In  most  cases  however,  the 
new  system  includes  some  additional  functions.  The  analyst, 
working  with  the  user,  reviews  the  logical  model  developed  in 
the  previous  step  and  adds  new  features  to  the  model  or  eli¬ 
minates  some  features.  The  final  product  will  be  a  logical 
model  of  the  system  that  the  user  had  in  mind  when  he  asked 
for  an  analyst. 

6 .  Develop  and  Evaluate  Alternative  Solutions 

With  the  agreed  logical  model  of  the  system  in  mind 
the  analyst  will  develop  a  variety  of  possible  solutions  to 
the  problem.  There  are  a  number  of  different  techniques  that 
can  help  the  analyst  to  generate  these  high-level  solutions. 
It  is  beyond  the  scope  of  this  thesis  to  describe  each  of 
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these  techniques.  A  simple  and  effective  method  is  described 
be  1 ow . 

First,  the  analyst  generates  a  set  of  alternatives 
without  considering  any  restrictions  or  constraints.  At  this 
point  he  may  think  of  any  system  that  could  possibly  solve 
the  problem:  a  manual  system,  a  fully  automated  system,  a 
batch  system  on  a  mainframe,  an  interactive  system  on  a  main¬ 
frame  or  on  a  microcomputer ,  a  DBMS  or  any  possible  combina¬ 
tion  of  such  systems. 

Next,  the  analyst  sould  consider  the  technical  feasi¬ 
bility  for  each  of  these  alternatives.  For  example  if  one 
passible  solution  is  to  create  a  data-base  system  on  a  micro¬ 
computer  using  a  DBMS  package  that  needs  more  memory  space 
than  is  available  on  the  micro,  then  this  system  must  be  dis¬ 
carded  . 

The  remaining  possible  solutions  are  examined  for  eco¬ 
nomical  feasibility.  In  other  words  the  alternatives  that  can 
not  be  accomplished  within  the  specified  scope  are  ignored. 

Finally,  political  feasibility  is  considered.  If,  for 
example,  one  solution  is  to  replace  or  reduce  the  number  of 
personnel  working  in  a  department  -  especially  in  a  goverment 
organization  -  this  may  present  a  serious  political  problem  in 
the  organization  and  it  is  very  probable  that  the  management 
would  not  accept  this  as  a  solution. 

7 .  Select  one  alternative 

Based  on  the  set  of  alternatives  that  have  passed  the 
above  feasibility  tests,  the  analyst  should  select  the  alter¬ 
native  that  he  believes  is  the  best.  Keep  in  mind  that  the 
management  usually  bases  its  decision  on  the  cost  savings  or 
the  positive  return  on  investment  relative  to  the  existing 


system.  Therefore  a  cost  /  benefit  analysis  should  accompany 
the  recommendation  for  an  alternative. 


8 .  Initiate  a  development  plan 

Assuming  that  management  accepts  the  alternative 
recommended  by  the  analyst,  they  need  to  know  how  long  it 
will  take  to  do  the  job,  how  many  people  from  the  organiza¬ 
tion  may  be  involved  and  what  is  the  approximate  cost  of 
each  step  in  the  process.  The  analyst  must  provide  this  infor — 
mation  in  the  form  of  an  initial  implementation  plan  of  the 
proposed  solution. 

9 .  Document  and  Present  the  Feasibility  Study 

The  analyst  collects  and  compiles  the  results  of  his 
feasibility  study  and  prepares  a  written  report.  There  is  no 
standard  format  for  the  feasibility  study  report.  The  analyst 
will  decide  which  is  the  best  way  to  document  his  work  during 
this  study.  However,  for  the  reader  who  feels  he  needs  a 
guideline,  Figure  C.3  in  [Ref.  10]  provides  an  outline  of  a 
typical  feasibility  study. 

B.  IMPLEMENTATION 

1 .  Confirm  the  Problem  Definition 

The  problem  definition  statement  prepared  during  the 
first  step  of  the  specification  stage  included  an  understand¬ 
ing  of  the  system  objectives  and  scope.  But  is  this  exactly 
what  the  director  of  the  SCD  had  in  mind  when  he  asked  for 
a  new  system?  The  first  task  is  to  confirm  that  the  problem 
definition  is  correct. 

The  problem  is  with  the  performance  of  the  Soldiers 
Section  of  the  Personnel  Office  in  the  SCD  which  is  headed 
by  a  colonel.  He  is  the  one  who  suggested  that  a  better 
personnel  management  system  is  needed.  The  analyst  visits 
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him  and  asks  if  he  agrees  with  his  view  of  the  problem.  He 
confirms  that  the  objectives  are  clearly  stated,  but  he 
thinks  that  the  scope  is  too  costly.  The  SCD  is  not  willing 
to  allocate  more  than  *15,000  for  this  project.  Therefore 
the  scope  of  the  system  is  changed  to  accomodate  a  cost  of 
*15,000.  Now  both  the  scope  and  objectives  have  been  con- 
f i rmed  . 

2 .  Study _ the  existing  system 

The  main  purpose  of  this  step  is  to  understand  the 
existing  system.  If  it  is  known  what  the  existing  system 
does,  then  it  is  easier  to  find  one  or  more  ways  to  design 
a  new  system  that  eliminates  the  problems. 

The  sources  of  information  that  will  help  in  the 
understanding  of  the  existing  system  are  two:  people  who  work 
in  the  system  and  documents  (reports,  forms  etc)  used  or 
produced  by  the  svstem.  During  the  interview  the  Colonel  in¬ 
dicated  that  the  best  source  of  information  is  his  assistant. 
The  interview  with  this  officer  led  the  analyst  to  interviews 
with  some  other  key  people  inside  and  outside  the  SCD  and 
finally  he  came  up  with  the  following  description  of  the 
system : 

New  soldiers  enter  the  Signal  Corps  every  two  months. 
On  the  first  day  of  each  odd  month  a  new  group  of  draftees 
reports  to  the  Enlistment  Center  (EC)  where  they  are  examined 
for  physical  and  mental  ability.  The  EC  then  prepares  a  list 
with  the  names  and  other  information  of  the  soldiers  who  were 
judged  acceptable  and  sends  one  copy  to  the  Basic  Training 
Center  (BTC)  and  one  to  the  SCD. 

Those  draftees  found  capable  of  becoming  soldiers  are 
sent  to  the  BTC  where  they  receive  training  for  two  months  in 
the  basic  subjects  that  every  soldier  must  know.  The  average 
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number  of  soldiers  tnat  enter  the  Signal  Corps  every  two 
months  is  about  1,000. 

The  SCD  matches  the  number  of  new  soldiers  with  the 
general  needs  for  specialized  personnel  and  calculates  the 
number  of  soldiers  that  must  be  trained  in  each  of  the  15 
different  specialties.  One  list  with  these  numbers  is  sent 
to  the  BTC  which,  after  interviews  with  the  soldiers,  decides 
in  which  specialty  each  soldier  will  be  trained. 

The  BTC  prepares  a  list  with  the  names  of  the  soldiers 
and  the  specialty  selected  for  each  one  and  sends  one  copy  to 
the  SCD  for  information  and  one  copy  to  the  Special  Training 
Center  (STC)  to  assist  in  scheduling  the  training  of  the  new 
incoming  soldiers. 

After  the  end  of  their  basic  trainig  the  soldiers  are 
sent  to  the  STC  where  they  will  receive  training  in  the  speci¬ 
alty  they  were  assigned.  The  duration  of  this  training  is 
one,  two,  or  three  months,  depending  on  the  specialty.  One 
week  before  the  end  of  the  training  of  each  specialty  the 
STC  sends  a  report  to  the  SCD  with  the  names  of  the  trained 
soldiers. 

The  SCD,  based  on  this  report  and  the  personnel  needs 
of  the  Signal  Corps  units,  selects  the  units  to  which  the 
newly  trained  soldiers  will  be  assigned  and  sends  a  copy  of 
the  assignments  list  to  the  STC  and  the  interested  units.  This 
procedure  takes  place  during  the  first  five  days  of  each 
man  th . 

Each  unit  of  the  Signal  Corps  submits  two  reports 
to  the  SCD  at  the  end  of  each  month.  The  first  includes  the 
names  of  the  soldiers  who  retired  or  were  separated  from  act¬ 
ive  duty  during  the  month  and  the  second  includes  the  changes 
(if  any)  in  the  status  of  the  soldiers  in  the  unit.  The  SCD 
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uses  these  reports  to  update  the  soldiers'  individual  files 
and  the  units  files. 

The  above  description,  although  very  general,  is  suf¬ 
ficient  for  understanding  the  current  system.  Of  course 
during  the  study  of  the  system  notes  have  been  taken  on  many 
details  that  will  help  later  to  design  the  new  system.  For 
example,  copies  of  the  various  lists,  reports  or  forms  that 
are  produced  or  used  by  the  system  were  requested. 

The  main  observations  about  the  existing  system  are 
described  below. 

(1)  The  basic  functions  that  the  Soldiers  Section  in  the 
Personnel  Office  performs  are  as  follows: 

-  Calculates  the  number  of  soldiers  that  must  be  trained 
in  each  specialty. 

-  Updates  the  soldiers'  files. 

-  Updates  the  units'  files. 

-  Performs  the  assignments  of  the  soldiers. 

(2)  The  Personnel  Office  does  not  exist  in  a  vacuum.  A 
number  of  other  organi zations  (EC,  BTC,  STC  and  units) 
must  provide  it  with  timely  information  in  order  to  be 
able  to  accomplish  its  mission.  The  delays  reported  in 
the  problem  definition  have  their  primary  origin  in  the 
untimely  arrival  of  these  data. 

(3)  Almost  all  the  procedures  that  take  place  in  the  system 
are  purposely  concentrated  at  the  beginning  or  the  end 
of  each  month.  This  makes  the  problem  of  manually 
sync hron i z ing  these  procedures  even  more  complicated  and 
the  presence  of  errors  more  likely. 

(4)  The  volume  of  information  that  is  manipulated  is  so 
large  that  it  is  almost  impossible  to  evaluate  the 
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soldiers'  requests  when  performing  the  assignments  with 
a  manual  system. 

(5)  The  general  observation  is  that  the  existing  system  is 
we i 1  designed  and  the  problems  that  have  been  reported 
are  mainly  caused  by  the  relative  difficulty  that 
charac teri zes  manual  systems  in  dealing  with  great 
volumes  of  information  under  pressure  of  time. 

3 .  Develop  a  high-level  model 

Now  that  the  analyst  has  an  understanding  what  the 
existing  system  does,  the  next  step  is  to  construct  a  high- 
level  logical  model  of  the  system.  This  model  will  assist 
in  the  design  of  the  new  system.  It  can  also  be  used  as  a 
communications  tool  with  the  people  in  the  Personnel  1  Office 
and  the  Management. 

There  are  many  techniques  for  describing  a  physical 
system.  Some  analysts  prefer  the  systems  flowcharts.  Others 
think  that  data  flow  diagrams  are  better.  The  Data  Flow 
Diagram  ( DFD )  will  be  used  to  describe  the  personnel  system. 
The  reason  is  that  at  this  early  stage  in  the  process  physical 
implementation  details  should  be  avoided.  The  analyst  wants  to 
summarize  the  functions  that  are  performed  by  the  system,  but 
not  to  be  influenced  by  the  specific  way  in  which  these 
functions  are  performed  by  the  existing  system.  The  DFD  is 
excellent  for  a  high-level  description  of  a  system  because  it 
stresses  functional  rather  than  physical  implementation.  It  is 
also  a  diagram  that  is  very  easy  to  understand.  There  are  only 
four  symbols  used  in  this  diagram  (fig. 4.1).  A  source  or 
a  destination  of  data  is  represented  by  a  square;  a  process 
in  the  system  that  transforms  data  by  a  circle  or  a  rectangle 
with  rounded  corners;  a  data  store  by  an  open-ended  rectangle 
and  data  flow  by  an  arrow. 
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Source  or  destination  of  data 


In  order  to  develop  a  DFD  of  the  system,  its  four  ele¬ 
ments  must  be  identified,  begining  with  an  identification  of 
the  sources  and  destina rions .  From  the  description  of  the 
system  it  is  determined  that  there  are  four  sources  or  desti¬ 
nations  of  data:  the  EC,  BTC,  STC,  and  the  units. 

After  reviewing  the  system  description  it  is  found 
that  the  processes  the  system  performs  are: 

-  Update  Soldiers  files 

-  Update  Units  files 

-  Estimate  the  number  of  soldiers  for  each  specialty 

-  Perform  ass i gnemen ts . 

The  description  of  the  system  is  reviewed  again, 
identifying  the  data  flows  and  the  data  stores.  At  the  end  of 
the  enlistment  the  EC  sends  a  list  with  the  soldiers  who 
joined  the  Signal  Corps  to  the  SCO.  This  list  is  a  data  flow. 
Is  it  also  a  data  store?  The  purpose  of  this  list  is  to  update 
the  soldiers'  files.  Most  of  the  time,  this  updating  is  not 


22 


performed  immediately  after  the  list  is  received.  Therefore 
a  data  store  is  needed  to  keep  the  data  until  the  user  is 
ready  to  use  them.  Continuing  in  the  same  way  the  remainder  of 
the  data  flows  and  data  stores  are  identified. 

The  next  step  is  to  develop  the  DFD  (Figure  4.2).  Note 
that  the  Processes  and  the  Data  Stores  are  numbered  so  that 
the  reference  to  them  is  facilitated. 


Figure  4.2  The  Data  Flow  Diagram  of  the  existing  system 


4 .  Confirm  the  logical  model 

One  of  the  major  advantages  of  a  DFD  is  that  it  is  an 
excellent  communications  tool.  Thus  it  can  be  used  to  explain 
our  understanding  of  the  system  to  the  management. 


The  DFD  is  presented  to  the  Colonel  and  he  agrees  that 
this  is  a  good  and  accurate  representation  of  the  system.  He 
also  reminds  the  analyst  that  the  details  of  the  implementa¬ 
tion  of  the  Assignments  process  will  be  changed  to  meet  the 
soldiers  needs.  There  is  no  need  to  change  any  other  process 
in  the  system. 

5 .  Develop  and  Evaluate  Alternative  Solutions 

The  analyst  now  faces  the  question  of  how  to  solve  the 
problem.  He  must  consider  and  evaluate  several  possible  solu¬ 
tions  . 

One  simple  solution  could  be  to  improve  the  manual 
procedures  of  the  existing  system.  It  is  true,  however,  that 
people  are  not  very  effective  when  dealing  with  large  amounts 
of  complex  data.  Therefore,  the  use  of  a  computerized  system 
would  be  better.  Should  a  traditional  file  processing  or  a 
database  system  be  used?  Database  processing  has  a  number  of 
advantages  over  the  file  systems.  These  advantages  become 
clearer  as  the  volume  and  complexity  of  data  increases.  Clearly 
it  is  better  to  choose  a  Database  system.  On  what  computer 
should  the  database  be  implemented?  The  Generel  Staff  has  its 
own  Computer  Center  that  runs  a  number  of  applications,  such 
as  payroll,  mobilization  procedures  etc.  There  is  enough 
capacity  to  run  our  database  on  the  mainframe.  There  are  some 
disadvantages  to  this  solution,  however.  The  director  of  the 
Personnel  Office,  would  not  have  complete  control  of  the 
soldiers'  management.  Also  it  is  very  likely  that  sooner  or 
later  the  other  Arms  will  ask  to  use  the  mainframe  for  their 
needs,  but  the  Computer  Center  as  it  is  now  organized  cannot 
undertake  the  management  of  all  the  Greek  army  soldiers. 

Another  way  is  to  have  a  centralized  machine  in  the 
SCD  with  a  centralized  database  and  implement  some  kind  of  a 
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network  with  the  SCD  as  the  central  node  and  the  EC,  BTC,  STC 
and  the  units  as  peripheral  nodes.  This  may  appear  to  be 
extremely  expensive  but  it  is  not  necessary  to  implement  a 
hardware  network.  For  example  the  data  could  He»  trans  f <=>^ed  via 
courier.  The  advantage  of  this  fully  centralized  database  is 
that  it  guarantees  the  integrity  of  data  and  it  also  helps  the 
other  units  to  benefit  from  the  system  by  automating  part  of 
their  work.  This  solution  also  would  put  full  control  of  the 
whole  system  in  the  hands  of  the  director  of  the  Personnel 
Office,  something  very  important  for  elimination  of  delays  and 
other  timing  problems.  The  only  disadvantage  is  that  this  is 
still  a  very  expensive  solution,  far  beyond  the  scope  of  the 
pro j ec  t . 

Finally,  a  third  way  is  to  implement  the  database  on  a 
mic rocompu ter  system.  This  microcomputer  would  be  positioned 
in  the  Personnel  Office.  The  data  from  the  units  outside  the 
SCD  will  continue  to  be  delivered  in  the  same  way  (manually 
written  reports  or  lists)  and  entered  into  the  computer.  All 
the  functions  performed  by  the  Personnel  Office  will  be  auto¬ 
mated,  speeding  up  execution  time  and  eliminating  delays 
caused  by  the  people  in  the  office,  but  it  does  not  address 
delays  from  outsiders.  One  possible  disadvantage  of  using  a 
microcomputer  is  that  it  may  impose  a  limit  in  growth  which 
means  that  we  are  not  going  to  be  able  to  go  beyond  micro¬ 
computer  storage  capability.  One  of  the  advantages  of  this 
solution  is  that  it  solves  the  delay  and  error  problems  inside 
the  SCD.  Even  more  important  is  that  this  system  is  able  to 
solve  the  soldiers'  assignments  problem,  which  is  one  of  our 
major  objectives.  Another  benefit  of  this  system  is  that  it 
can  be  easily  expanded  to  the  other  Arms. 
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What  would  be  the  cost  of  such  a  system?  First  the 
type  of  microcomputer  that  would  be  appropriate  for  this 
database  must  be  determined.  The  main  datastore  is  the  SOLDIER 
file  which  contains  about  10,000  records,  with  each  record 
having  about  400  characters.  There  is  always  an  overhead  of 
about  20‘/.  for  pointers,  links  etc,  which  results  in  about  500 
characters  per  record .  Therefore  the  total  memory  space  needed 
for  this  file  is:  10,000  x  500  =  5  Mbytes.  If  an  IBM/AT  micro¬ 
computer  with  a  20  Mbyte  hard  disk  is  considered,  the  system 
can  be  implemented.  The  cost  of  such  a  microcomputer  together 
with  the  appropriate  peripherals  is  about  $6,000. 

6 .  Select  one  Alternative 

The  analyst  feels  that  the  idea  of  using  the  General 
Staff  mainframe  is  the  least  desirable  -  by  almost  everyone.  The 
network  solution  is  the  most  attractive  but  far  beyond  the 
given  scope  limits.  The  solution  of  implementing  a  database  on 
a  microcomputer  is  well  within  the  limits  of  both  the  scope 
and  the  objectives  of  the  project  and  this  is  what  the  analyst 
will  recommend . 

7 .  Initiate  a  Development  Plan 

The  purpose  of  this  step  of  the  feasibility  study  is 
to  provide  the  management  with  a  rough  implementation  plan  of 
the  proposed  solution,  together  with  an  estimate  of  the 
approximate  costs  for  each  step  in  the  plan. 

The  implementation  schedule  prepared  by  the  analyst  is 
shown  in  Figure  4.3.  Note  that  this  is  a  rough  estimate  of  the 
implementation.  The  cost  figures  were  calculated  on  the  basis 
of  the  salary  of  a  major  (usual  rank  of  an  analyst).  The  total 
cost  of  this  system  will  be  $14,000  ($6,000  for  hardware  plus 
$8,000  for  implementation). 
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STEP 

PERSONNEL 

T 1  ME  ( mon  t  hs ) 

ELAPSED 

TIME  ( months ) 

COST 

Feas 1 bi 1 l ty 

0. 5 

Completed 

* 

1 ,000 

Analysis 

1.0 

1 .0 

% 

2,000 

Desian 

1 . 5 

1 . 5 

% 

3,000 

I mp 1 emen  cation 

1 .0 

1.0 

% 

2,000 

TOTAL 

4.0 

3.5 

% 

8,000 

Figure  4.3  The  implementation  plan 

B •  Document  and  present  the  Feasibility  Study 

The  feasibility  study  is  now  completed.  The  analyst 
writes  a  report  including  the  results  that  he  thinks  are 
necessary  to  support  his  recommendation.  Then  he  presents  his 
report  in  a  meeting  with  the  director  of  the  Personnel  Office 
and  the  director  of  the  SCD.  They  agree  with  the  proposed 
solution  and  schedule.  Now  the  analyst  is  ready  to  move  to  the 
next  step  in  the  process:  the  analysis. 
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V.  ANALYSIS 


A .  THEORY 

1 .  The  Purpose  of  the  Analysis  Phase 

The  purpose  of  analysis  is  to  define  the  system  in 
terms  of  what  is  to  be  produced.  The  question  of  how  the 
system  will  provide  the  required  features  will  be  answered 
later,  during  the  design  phase.  Therefore,  analysis  is  a 
logical  process  which  does  not  really  solve  the  problem,  but 
decides  what  should  be  done  to  solve  it.  It  is  obvious  that 
the  importance  of  this  stage  is  paramount.  Decisions  made  here 
will  influence  the  rest  of  the  development  process. 

Many  studies  have  been  conducted  which  document  that 
system  analysis  errors  are  extremely  expensive  to  correct, 
especially  if  they  are  discovered  late  in  the  system  develop¬ 
ment  process.  Figure  5.1  fRef.  11]  illustrates  the  relative 
cost  to  make  a  change  as  a  function  of  the  phase  in  which  the 
change  is  made.  Note  it  is  about  100  times  as  costly  to  cor¬ 
rect  a  specification  error  during  system  testing  as  it  is  to 
correct  it  during  analysis. 

Another  stydy  by  James  Martin  also  documented  that 
about  50'/.  of  the  number  of  errors  and  75’/.  of  the  cost  of  error 
correction  in  operational  systems  is  caused  by  errors  during 
analysis.  Finally  there  is  strong  empirical  connection  between 
failure  to  define  a  system  adequately  during  analysis  and 
failure  to  produce  it.  Nevertheless  a  great  number  of  managers 
and  users  think  of  analysis  as  a  time  consuming  process  that 
must  be  minimized.  This  attitude  has  its  origin  in  older  times 
when  coding  was  really  the  dominating  process  in  system  deve- 
1 opmen  t . 
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Figure  5.1  Relative  cost  to  correct  an  error 

The  main  deliverable  of  the  Analysis  phase  is  a 
document  called  Functional  Specification  or  System  Definition. 
Very  often  this  document  is  considered  as  being  a  training 
manual,  an  operational  handbook,  or  a  management  summary,  but 
it  is  not.  The  only  purpose  of  this  document  is  to  provide  a 
specification  of  the  functions  to  be  performed  by  the  system 
and  the  constraints  within  which  it  must  work.  The  Functional 
Specifications  will  become  the  starting  point  for  the  Design 
phase  that  follows  analysis.  Depending  on  the  size  and 


complexity  of  the  system,  the  functional  specifications 
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document  may  consist  of  a  few  pages,  or  it  may  be  packaged 
in  several  volumes. 

2 .  Techniques  of  use  durina  Analysis 

Unfortunately,  as  was  also  the  case  with  the  Feasibi¬ 
lity  Study,  there  is  no  universally  adopted  method  for  the 
Analysis  phase  and  the  system's  functional  specifications  are 
sometimes  produced  without  following  any  method  at  all. 

Because  of  the  great  importance  of  this  phase,  many 
attempts  have  been  made  by  computer  science  people  to  bring 
a  level  of  formalism  to  the  production  of  the  functional 
spec i f ications .  As  a  result  of  this  effort  a  great  number  of 
different  techniques  have  been  produced.  These  techniques 
range  from  manually  driven  techniques  to  fully  computerized 
ones.  Some  of  them  provide  a  way  to  generate  the  system  defi¬ 
nition,  whatever  form  this  may  take.  Others  simply  provide 
a  way  of  presenting  the  definition.  The  best  technique  is  one 
that  combines  both  results  for  the  system  definition  process. 
Again  some  techniques  are  very  effective  in  certain  aspects 
and  for  particular  types  of  systems.  For  the  reader  who  is 
interested  in  the  details  of  any  particular  analysis  technique, 
the  names  of  the  most  popular  ones  together  with  the  reference 
of  a  description  of  the  technique  follow: 

-  Structured  Analysis.  [Ref.  12] 

-  PSL/PSA .  [Ref.  13] 

-  Sructured  Analysis  and  Design  Technique  ( SADT ) .  [Ref.  14] 

-  Controlled  Requirements  Expression  (CORE).  [Ref.  15] 

-  Software  Requirements  Engineering  Methodology.  [Ref.  16] 

-  Finite  State  Machines  (FSM).  [Ref.  17] 

-  Petri  Nets.  [Ref.  IB] 

-  Jackson  System  Development  (JSD).  [Ref.  19] 

-  Software  Development  System  (SDS/RSRE).  [Ref.  20] 
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All  of  these  techniques  in  some  way  model  the  system 
being  defined.  The  difference  is  that  each  technique  focuses 
on  a  different  aspect  of  the  system  such  as  data  flow,  data 
structure,  control  of  flow,  etc.  Therefore,  before  choosing 
an  analysis  technique  one  should  first  identify  which  aspect 
of  the  system  is  the  most  important.  In  the  following  section 
a  very  brief  and  simplified  description  of  the  Structured 
Analysis  method  [Ref.  12]  is  given  and  will  be  followed  during 
the  implementation  of  the  Analysis  phase. 

3 .  A  brief  description  of  Structured  Analysis 

De  Marco  [Ref.  12]  and  Gane  and  Sarson  [Ref.  21]  have 
defined  a  methodology  which  is  primarily  involved  with  the 
application  of  a  particular  set  of  tools  to  the  production 
of  a  Structured  Functional  Spec i f ication .  These  tools  are: 

The  Data  Flow  Diagrams,  the  Data  Dictionary  and  Process 
Description  Tools.  The  Data  Flow  Diagrams  (DFD)  and  their  use 
were  described  in  Chapter  IV. 

The  Data  Dictionary  ( DD )  is  used  to  define  the  data 
flows  and  data  stores  that  appear  in  the  DFDs.  In  other  words 
the  DD  is  a  collection  of  data  about  data.  The  basic  idea  is 
to  provide  information  on  the  definition,  structure  and  use  of 
each  data  element  an  organization  uses.  A  data  element  is  a 
unit  of  data  that  cannot  be  decomposed.  A  DD  usually  consists 
of  a  listing  of  all  elements  found  in  each  data  store.  For 
each  data  element,  information  about  its  name,  aliases  or 
synonyms,  description,  format,  location  and  other  characteri¬ 
stics  is  recorded  in  the  DD. 

The  Process  Description  Tools  are  used  to  define  the 
processes  in  the  DFD  that  cannot  be  further  decomposed  and  are 
called  primitive  processes  (or  primitives).  Primitives  are  not 
described  in  terms  of  further  DFDs  and  so  require  some  other 
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means  of  definition.  Structured  Analysis  uses  Structured 
English,  Decision  Tables  and  Decision  Trees  for  this  purpose. 
For  each  of  the  primitive  processes  a  description  called 
mini-spec  is  written  using  these  tools. 

One  way  to  produce  the  Functional  Requirements  using 
the  Structured  Analysis  tools  is  described  below. 

First  explode  thfe  DFD  which  was  produced  during  the 
Feasibility  study  by  taking  each  process  in  the  DFD  and 
breaking  it  down  into  its  subfunctions.  These  lower  level 
functions,  together  with  their  own  data  stores  and  data  flows, 
become  processes  on  a  new  more  detailed  version  of  the  DFD. 
This  decomposition  continues  to  the  point  of  code  generation, 
at  which  the  analysis  phase  ends. 

The  next  step  is  to  define  the  data  flows  and  stores 
down  to  the  element  level.  For  each  process  in  the  exploded 
DFD  the  elements  that  must  appear  in  the  output  and  input  are 
identified.  Then  a  list  is  made  of  each  data  store  and  data 
flow  together  with  the  data  elements  it  contains.  Final lv,  the 
DD  is  constructed  in  which  information  is  recorded  about  the 
name,  description,  format,  use,  etc  of  each  data  element. 

The  third  step  during  Structured  Analysis  is  to 
describe  each  process  at  a  high  level,  using  Structured 
English,.  Decision  Tables  or  Decision  Trees. 

Note  that  this  process  is  not  linear.  For  example, 
while  the  analyst  is  defining  the  data  elements  he  may  find 
that  he  must  go  back  and  change  the  DFD,  or  a  process  descrip¬ 
tion  might  imply  the  addition  of  new  data  elements  in  a  data 
store . 

The  exploded  DFD,  the  Data  Dictionary  and  the  process 
descriptions  form  the  Functional  Specifications  of  the  system, 
which  after  being  reviewed  and  approved  by  the  user,  are  pre¬ 
sented  to  the  management. 
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B.  1  HE  IMPLEMENTATION  OF  STRUCTURED  ANALYSIS 


1 .  Explode  the  Data  Flow  Diagram 

The  DFD  developed  during  the  Feasibility  study  phase 
(Fig.  4.2)  is  the  starting  point  for  the  Analysis  phase.  This 
DFD  contains  four  processes,  one  for  each  major  function  in 
the  Personnel  Office.  During  this  phase  the  analyst  will  con¬ 
sider  each  process  separately  and  try  to  decompose  it  into 
lower-level  processes. 

a.  Decompose  process  Pi 

Consider  the  first  process,  PI.  The  purpose  of 
this  process  is  to  calculate  how  many  of  the  new  enlisted 
soldiers  are  needed  to  tre  n  in  each  specialty.  Figure  5.2 
shows  the  DFD  of  this  process. 


Figure  5.2  The  DFD  for  process  Pi 

Trying  to  decompose  PI  we  find  that  it  cannot  be 
divided  into  functional  groups  to  form  separate  processes. 
Therefore  process  PI  will  not  be  further  decomposed, 
b.  Decompose  process  P2 

The  DFD  for  process  P2  is  shown  in  figure  5.3. 
This  process  updates  the  Soldiers  file  with  information  from 
the  following  incoming  data  stares:  Di  (new  enlisted  soldiers), 
D3  (soldiers  who  completed  specialty  training),  D6  (assign¬ 
ments),  D7  (changes  of  status)  and  D8  (retired  soldiers). 
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Figure  5.3  The  DFD  of  original  process  P2 

These  subfunctions  are  performed  by  this  process: 

-  P2.1  :  Add  new  records  to  Soldiers  file. 

-  P2.2  :  Update  records  in  Soldiers  file. 

-  P2 . 3  :  Delete  records  from  Soldiers  file. 

The  new  Data  Flow  Diagram  for  process  P2  after 


this  decomposition  is  shown  in  figure  5.4. 


Figure  5.4  Decomposition  of  process  P2 
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Some  of  the  processes  in  this  new  DFD  require 
further  decomposition.  For  example  process  PZ.Z  uses  three 
different  data  stores  that  enter  the  system  at  different  times 
to  update  the  Soldiers  file.  Therefore  it  could  be  decomposed 
into  three  subfunctions  shown  in  figure  5.5. 


Figure  5.5  Decomposition  of  process  P2 . 2 


e.  Decompose  process  P3 

The  function  of  Po  is  to  update  tne  Units  file 
with  the  information  contained  in  the  data  stores  D6  (assign¬ 
ments'  and  D6  (retired  soldiers ) .  Figure  5.6  shows  the  origi¬ 


nal  version  of  the  DFD  for  this  process. 


Figure  5.6  The  DFD  for  process  P3 


55 


The  explosion  of  process  P3  is  shown  in  figure  5.7 
Two  new  processes  are  created: 

-  P3.1  :  Update  the  Units  file  with  the  retired  soldiers. 

-  P3.2  :  Update  the  Units  file  with  the  new  assignments. 


Figure  5.7  Decomposition  of  process  P3 


d.  Decompose  process  P4 

Finally  process  P4  is  considered.  This  process  is 
used  to  assign  the  newly  trained  soldiers  to  units.  The  Data 
Flow  Diagram  for  P4  is  shown  in  figure  5.8. 


Figure  5.8  DFD  of  process  P4 


Three  subfunctions  of  process  P4  can  be  identified 
as  follows.  The  first  subfunction  (process  P4 . 1 )  uses  data 
store  D3  (soldiers  who  completed  specialty  training)  to  deter¬ 
mine  who  is  going  to  be  transfered  and  data  store  D4  (soldiers 
to  get  information  about  each  soldier.  This  information  is 
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used  by  P4 . 1  to  calculate  the  transfer  points  for  each  soldier 
that  will  decide  the  priority  *n r  transfer  among  the  soldiers. 
Thus  the  need  for  a  new  data  store  Dll  (Soldier  Qualification 
Points)  to  store  this  information  is  identified. 

The  second  subfunction  (process  P4.2)  uses  date' 
store  D3  to  get  the  number  of  soldiers  to  be  assigned  and  data 
store  D5  (Units)  to  read  the  number  of  existing  and  required 
soldiers  in  each  unit.  It  then  calculates  the  number  of  soldi¬ 
ers  of  each  specialty  that  will  be  assigned  to  each  unit.  This 
information  will  be  recorded  in  a  new  data  store  D12  (Unit 
Needs  )  . 


Finally,  a  third  subfunction  (process  P4 . 3 )  will 
assign  each  soldier  to  a  unit  using  the  information  contained 
in  the  data  stares  Dll  and  D12. 

The  decomposition  of  process  P4  is  shown  in  figure 


5.9. 


Figure  5.9  Decomposition  of  process  P4 
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2. 


Define  the  Data  Elements 


One  objective  of  analysis  is  to  define  the  data  flows 
and  data  stores  down  to  the  element  level.  To  accomplish  this 
each  process  in  the  data  Flow  Diagram  is  considered  separately 
and  the  data  that  must  appear  as  its  outputs  and  inputs  are 
defined . 

a.  Using  process  PI 

Process  PI  calculates  the  number  of  soldiers  to 
be  trained  in  each  specialty.  Therefore  its  output,  which  is 
stored  in  data  store  D2,  will  contain  at  least  two  elements: 
The  SPECIALTY  and  the  REQUIRED  SOLDIERS  per  specialty. 

To  calculate  the  Required  Soldiers,  process  PI 
uses  the  fallowing  elements: 

(1)  Total  number  of  new  enlisted  soldiers. 

(2)  Total  number  of  soldiers  per  specialty 
required  to  satisfy  the  current  unit's  needs. 

(3)  Total  number  of  soldiers  per  specialty 
to  retire  in  the  next  4  months. 

(4)  Number  of  soldiers  currently  undergoing 
training  in  each  specialty. 

Data  store  D1  (New  Enlisted  Soldiers)  provides 
information  for  element  (1).  Therefore,  D1  must  contain  a 
field:  TOTAL  NUMBER  OF  ENLISTED  50LDIERS. 

Next  consider  element  (2).  Data  store  D5  (Units) 
in  the  form  that  it  is  used  now  consists  of  a  UNIT  NAME  field 
followed  by  one  field  for  each  SPECIALTY,  which  is  divided 
into  subfields  for  the  EXISTING,  REQUIRED  and  COMPLEMENT 
number  of  soldiers  for  this  Specialty.  Thus,  element  (2)  can 
be  calculated  by  adding  all  the  Complement  fields  of  one 
specialty  in  all  units. 
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As  for  element  (3)  the  remaining  time  of  service 
for  each  soldier  is  needed.  One  way  to  obtain  this  information 
is  to  include  a  field  REMAINING  TIME  in  D4 .  Process  PI  will 
read  this  number  for  each  soldier  and  decide  if  it  is  greater 
or  less  than  4  months.  But  the  Remaining  Time  of  Service  is 
a  value  that  must  be  continuously  updated  (it  changes  every 
day).  Is  there  a  more  convenient  way  to  derive  the  desired 
information?  One  way  is  to  calculate  the  date  when  the  remai¬ 
ning  service  time  becomes  4  months.  Then  PI  will  compare  the 
current  date  with  this  date  and  if  the  current  date  is  already 
past  this  date  then  the  remaining  time  will  be  less  than  four 
months.  This  date  is  calculated  by  adding  the  duration  of 
service  to  the  date  of  enlistment  to  get  the  retirement  date 
and  then  subtract  4  months  from  it.  Therefore  data  store  D4 
must  provide  the  elements  DURATION  of  SERVICE  and  DATE  of 
ENLISTMENT.  For  purposes  of  speeding  up  the  execution  of  PI, 
it  may  be  better  to  store  this  date  in  D4  after  it  is  calcula¬ 
ted  for  the  first  time. 

Finally,  element  (4)  (i.e.,  the  number  of  soldiers 
currently  enrolled  in  training  in  a  given  specialty  X)  must  be 
calculated.  We  should  be  able  to  find  this  number  by  counting 
the  number  of  records  in  D4  with  COMPLETED  TRAINING  —  False 
and  SPECIALTY  =  X.  Unfortunately  the  SPECIALTY  field  cannot 
be  updated  before  the  completion  of  specialty  training.  There¬ 
fore  a  new  data  store  will  be  needed  to  provide  the  soldiers 
enrolled  in  training  in  each  specialty.  This  will  become  data 
store  D14  (CURRENTLY  TRAINING  SOLDIERS)  and  it  will  contain 
the  fields  ID_NUMBER  and  SPECIALTY.  This  data  store  will  be  a 
list  submitted  by  the  Training  Center  every  month  together 
with  D3 . 
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The  needed  number  of  soldiers  per  specialty  can 


now  be  determined  if  the  specialty  name  is  known.  None  of  the 
data  stores  in  the  DFD  seems  to  contain  this  information, 
though.  Obviously  something  is  missing.  The  user  is  asked 
where  the  names  of  the  specialties  are  stored.  The  answer  is 
that  they  do  not  use  a  data  store  for  the  names  of  the  ten 
specialties,  because  they  can  easily  remember  them  or  they  can 
look  them  up  on  a  piece  of  paper,  obviously  not  feasible  for  a 
computerized  application.  A  new  data  store  is  required  to  keep 
the  names  of  the  specialties.  This  data  store  will  be  D9  (SPE¬ 
CIALTIES)  with  one  data  element  SPECIALTY  NAME. 

The  DFD  of  process  PI  is  updated  to  show  the  new 
data  stores  D9  and  D14  (Figure  5.10). 


Figure  5.10  Process  PI  after  the  addition  of  D9  and  D14 


Following  is  a  list  of  the  data  stores  used  by 
process  PI,  together  with  the  data  elements  they  contain: 

-  D1  :  NEW  ENLISTED  SOLDIERS 

1.  Total  number  of  enlisted  soldiers 

-  D2  :  REQUIRED  SOLDIERS  FOR  EACH  SPECIALTY 

1 .  Spec ia 1 ty 

2.  Required  soldiers  for  specialty  training 
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-  D4  :  SOLDIERS 

1.  Date  Enlisted 

2.  Service  duration 

3.  Date  when  remaining  service  equals  four  months 

-  D5  :  UNITS 

1.  Unit  name 

2.  Specialty 

3.  Required  number  of  soldiers 

4.  Existing  number  of  soldiers 

5.  Complement  number  of  soldiers 

-  D9  :  SPECIALTIES 

1.  Specialty 

-  D14:  CURRENTLY  TRAINING  SOLDIERS 

1 .  ID  number 

2.  Specialty 

b.  Using  the  remaining  processes  in  the  DFD 

Proceeding  in  the  same  manner  the  data  elements 
that  are  required  by  the  rest  of  the  processes  in  the  Data 
Flow  Diagram  are  identified.  New  data  stores  are  added  and  the 
DFD  is  expanded  where  necessary.  At  the  end  of  this  process 
the  DFDs  for  the  processes  PI  through  P4  have  taken  the  form 
shown  in  figures  A. 2  through  A. 5  of  Appendix  A.  Also  the  data 
stores  are  shown  in  section  B.l  of  Appendix  B.  Note  that  a 
new  data  store,  HISTORY,  was  added  to  keep  the  information 
about  a  soldier  after  he  has  retired  and  before  his  record  is 
deleted  from  the  Soldiers  file. 

3 .  Construct  the  Data  Dictionary 

For  each  data  element  already  registered  in  a  data 
store,  information  is  recorded  about  its  name,  aliases, 
description,  format,  location,  etc.  The  Data  Dictionary  is 
shown  in  sections  B.l  and  B.2  of  Appendix  B. 

4 .  Write  Process  Descriptions 

As  previously  discussed  the  purpose  of  this  step  is  to 
describe  each  process  in  the  DFD  at  a  high  level.  There  are 
many  available  tools  to  be  used  for  this  purpose  such  as, 
Decision  Tables,  Decision  Trees  and  Structured  English. 
Structured  English  was  chosen  to  document  the  processes.  The 
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complete  documentation  is  shown  in  figures  C.l  through  C.ll  of 
Appendix  C. 

5 .  Review  the  Functional  Requirements 

Working  with  the  user  the  Functional  Requirements  are 
reviewed  to  decide  if  they  are  complete. 

During  this  review  it  was  found  that  there  are  two 
more  processes  that  need  to  be  added  to  the  system. 

The  data  stores  D1 ,  D3,  D7 ,  D8  and  D14  enter  the 

system  in  manual  form.  The  computer  cannot  process  manual 
files.  Therefore  a  new  process  P5  (ENTER  DATA)  is  required 
which  will  transform  the  manual  data  stores  into  electronic 
files  that  can  be  manipulated  by  the  computer.  Figure  5.11 
shows  the  DFD  for  this  new  process.  The  exploded  process  P5  is 
shown  in  figure  A. 6  of  Appendix  A  and  its  algorithm  descrip¬ 
tion  in  sections  C.12  through  C.16  of  Appendix  C.  Finally  a 
last  process  P6  (GENERATE  REPORTS)  is  needed.  This  process 
prints  out  the  reports  that  the  Personnel  Office  of  the  SCD 


Figure  5.11  The  DFD  of  process  P5 


42 


must  send  to  the  training  centers  and  the  units  (i.e.,  the 
Assignments  list  and  the  list  with  the  Training  needs). 

The  Data  Flow  Diagram  for  process  P6  is  shown  in 
figure  5.12  and  its  exploded  form  in  figure  A. 7  of  Appendix  A. 
Also  the  algorithm  description  for  this  process  is  contained 
in  sections  C.17  and  C.18  of  Appendix  C. 


The  final  version  of  the  system  Data  Flow  Diagram  is 
shown  in  figure  A.l  of  Appendix  A. 

6 .  Present  the  Functional  Requirements  to  the  Management 
At  the  beginning  of  this  chapter  it  was  mentioned  that 
the  process  of  producing  the  Functional  Requirements  for  the 
system  is  not  linear.  Very  often  the  analyst  backtracks  and 
repeats  certain  steps  in  the  process.  Finally  it  is  felt  that 
the  Functional  Requirements  are  complete  and  they  are 
presented  to  the  management.  The  contents  of  Appendices  A,  B 
and  C  form  the  Functional  Requirements  of  the  system. 
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VI.  SYSTEM  DESIGN 


A .  THEORY 


1 .  The  Purpose  of  the  System  Design 

During  the  analysis  stage  the  analyst  defined  what  is 
going  to  be  produced.  The  next  step  is  to  answer  the  question 
of  how  to  produce  the  system  and  this  is  the  purpose  of  the 
Design  phase. 

The  majority  of  the  literature  that  exists  on  the 
different  steps  in  the  development  of  a  system  views  Design  as 
one  big  step  which  takes  the  Functional  Specifications  produ¬ 
ced  during  Analysis  as  its  input  and  designs  a  system  that 
satisfies  them.  A  number  of  people,  however,  believe  that  it 
is  better  to  break  the  Design  stage  in  two  phases:  System 

Design  and  Detailed  Design. 

During  System  Design  it  is  determined  in  general  how 
the  system  will  be  implemented  by  identifying  different  alter¬ 
native  solutions  and  selecting  one  alternative  that  best 
satisfies  the  system  needs. 

During  Detailed  Design  it  is  determined  how  spec  if ic- 
a 1 1 y  the  selected  alternative  should  be  implemented. 

However,  no  matter  which  design  approach  is  followed 
the  system  designer  must  always  keep  in  mind  that  the  final 
product  of  this  phase  should  be  a  system  design  which  first 
provides  all  the  required  functions  and  second  can  be  easily 
imp 1 emen  ted . 

2 .  Identify  Alternative  Solutions 

System  Design  begins  with  a  search  for  different 
systems  that  meet  the  user's  requ i remen ts .  To  make  this  search 
easier  each  one  of  the  systems  components  is  considered 
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separately.  A  system  usually  consists  of  four  components: 
Data,  Hardware,  Software  and  People. 

a.  Data  alternatives 

The  main  function  of  any  computer  system  is  data 
processing.  The  way  in  which  data  is  organized  greatly  affects 
the  system  structure  and  most  of  the  time  its  effectiveness. 
There  are  two  primary  data  alternatives. 

One  way  is  to  organize  data  in  f i 1 es .  which  exist 
independently  of  each  other,  and  their  structure  is  distribu¬ 
ted  across  the  application  programs.  Another  alternative  is  to 
utilize  a  database . 

There  are  advantages  and  disadvantages  related  to 
each  of  the  two  alternatives  and  the  system  designer  should 
evaluate  them  and  choose  the  one  that  best  satisfies  the  needs 
of  the  particular  application.  Sometimes,  a  combination  of 
these  two  alternatives  should  be  used. 

b.  Software 

The  evaluation  and  selection  of  the  appropriate 
software  for  the  system  is  usually  a  difficult  and  time  consu¬ 
ming  task.  During  this  step  different  programming  languages 
must  be  evaluated  that  can  be  used  to  write  the  applications 
programs.  The  operating  system  to  be  used  should  also  be  con¬ 
sidered.  The  most  difficult  decision,  however,  is  to  choose  a 
Data  Base  Management  System  (DBMS)  when  a  database  is  involved. 

The  functions  provided  by  a  DBMS  must  match  close¬ 
ly  the  user  requ i remen ts .  Unfortunately,  most  of  the  existing 
DBMSs  do  not  provide  the  same  functions  and  the  same  interfa¬ 
ces  and  therefore,  we  must  proceed  very  carefully  in  choosing 
the  correct  DBMS. 

Gordon  Everest  in  his  book  "Database  Management" 
has  devoted  a  whole  chapter  to  the  DBMS  selection  and  aquisi- 
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tion  process  [Ref.  22].  For  the  reader  who  needs  more  details 
on  this  process,  the  reference  provides  a  very  good  guide. 

There  is  a  substantial  difference  between  a  DBMS 
for  a  personal  computer  and  one  for  a  large  system.  First  of 
all  the  size  of  the  databases  that  must  be  managed  by  a  perso¬ 
nal  computer  DBMS  is  many  orders  of  magnitude  less  than  the 
size  of  a  commercial  database.  Also  the  personal  systems  are 
usually  intended  for  use  by  only  one  person,  while  the  large 
mainframe  systems  are  serving  concurrently  many  different 
applications  and  users.  Because  of  these  differences  a  commer¬ 
cial  DBMS  should  be  much  more  sophisticated  and  able  to 
coordinate  the  complex  database  activities.  Therefore,  it  is 
always  much  easier  to  select  one  of  the  many  low-cost  DBMS 
packages  available  in  the  market  for  microcomputers . 

c.  Hardware 

In  most  cases  the  management  wants  the  new  system 
to  run  on  existing  hardware.  If  this  is  possible  without  any 
major  additions  or  modifications,  it  is  wise  to  keep  the 
current  system  in  place.  Sometimes,  however,  new  applications 
require  a  new  computer  system.  Also  the  involvement  of  a 
database  usually  implies  the  use  of  special  hardware  with  more 
main  and  secondary  storage  space,  faster  CPU  etc.  The  DBMS 
vendor  will  provide  information  on  the  hardware  needed  to  be 
used  . 

d.  People 

Finally  the  people  who  are  involved  in  the  system 
are  considered.  We  must  decide  who  the  end-users  are  going  to 
be  and  the  extent  of  training  required. 

If  a  database  is  involved  then  it  must  be  decided 
whether  a  Data  Base  Admin i s tra tor  (DBA)  will  be  needed.  The 
function  of  the  DBA  is  "to  protect  the  database  and  to  ensure 
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that  it  is  structured  and  used  so  as  to  provide  maximum  bene¬ 
fit  to  the  community  of  users"  [Ref.  9:  p.  30].  When  a  great 
number  of  different  applications  and  users  are  using  the  data¬ 
base  the  presence  of  a  DBA  becomes  a  necessity.  The  DBA  could 
be  a  single  person  or  a  whole  team.  The  cost  of  the  DBA  staff 
should  be  considered  as  part  of  the  cost  of  the  alternative 
being  evaluated. 

3 .  Select  one  alternative 

The  next  step  is  to  select  one  of  the  different  alter¬ 
native  sets  of  the  system  components  identified  during  the 
previous  step. 

A  number  of  different  techniques  exists  that  assist  in 
the  selection  of  an  alternative  solution.  David  Kroenke 
[Ref.  9]  has  described  three  such  techniques  which  are  briefly 
reviewed  below. 

The  first  technique  is  called  Subjective  Evaluation. 
This  approach  is  the  cheapest,  quickest  and  most  frequently 
used.  The  purpose  is  to  subjectively  evaluate  each  alternative 
and  to  make  an  intuitive  decision.  Thus  the  criteria  for 
comparing  alternatives  are  first  identified.  Next  the  criteria 
are  weighted  according  to  their  relative  importance.  Then, 
each  alternative  is  subjectively  scored  by  the  members  of  the 
evaluation  team.  The  total  score  for  each  alternative  is  then 
calculated  and  the  alternative  with  the  highest  total  score  is 
se 1 ec  ted . 

Cost/benefit  analysis  is  another  technique,  which 
gives  a  reasonable  picture  of  the  costs  and  benefits  associa¬ 
ted  with  each  alternative  solution,  so  that  management  can 
compare  the  alternatives  and  decide  which  one  is  a  good 
investment.  First  the  costs  of  developing  each  alternative 
system  are  identified.  The  cost  of  each  phase  in  the  system 
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development  is  estimated  separately  and  the  total  cost  of 
development  is  the  sum  of  thes<=  costs.  Next  the  cost  of  main¬ 
taining  and  operating  the  system  after  it  is  implemented  is 
estimated  and  is  added  to  the  development  cost.  The  expected 
benefits  from  the  use  of  the  system  is  estimated  next. 

Note  that  the  development  costs  occur  only  once.  The 
operating  costs  and  the  benefits  occur  continuously  after  the 
system  becomes  operational  and  are  not  equally  distributed 
across  time.  Also,  as  is  the  case  with  most  computerized 
systems,  they  usually  become  obsolete  in  a  few  years.  Therefo¬ 
re  it  is  wise  to  estimate  the  return  on  investment  for  any 
system  for  a  period  no  longer  than  five  years.  If  the  benefits 
during  this  period  do  not  exceed  the  sum  of  the  development 
and  operation  costs  then  this  system  might  not  be  feasible. 

A  third  technique  suggested  by  Kroenke  is  to  use  a 
combination  of  both  of  the  above  techniques.  Subjective  evalu¬ 
ation  can  be  used  to  reduce  the  number  of  alternatives  tc  two 
or  three  and  then  perform  a  cost/benefit  analysis  on  these 
alternatives  to  choose  the  best  one. 

B.  THE  IMPLEMENTATION  OF  SYSTEM  DESIGN 
1 .  Identify  Alternative  Solutions 

During  the  Feasibility  Study  phase  a  number  of  alter¬ 
native  solutions  to  the  problem  were  developed  and  evaluated. 
The  result  of  that  evaluation  was  that  the  imp  1 emen tation  of  a 
database  system  on  a  microcomputer  is  the  most  desirable 
solution.  These  results  will  be  used  during  System  Design  to 
help  make  the  effort  of  identifying  alternative  solutions 
easier . 

a.  Data  Alternatives 

The  system  can  be  implemented  using  different  data 
processing  technologies.  One  way  is  to  continue  using  the 
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ex  l'btinq  manual  files  for  all  processes  in  the  system,  except 
for  t he  assignments  processing  for  which  traditional  file 
p r oc ess  1  rig  can  be  used.  Another  option  is  to  implement  the 
whole  svstem  using  file  processing.  Finally,  a  third  option 
is  to  store  all  data  in  a  single  database. 

b .  So  f t war e 

In  the  market  there  are  a  large  number  of  DBMSs 
(over  one  hundred)  that  run  on  microcomputers.  Most  of  these 
DBMSs  provide  a  programming  language  that  can  be  used  to  write 
application  proqrams  when  all  processing  requirements  cannot 
tie  handled  by  the  database  functions  provided  by  the  DBMS. 
Some  of  these  full  function  DBMSs  are  listed  below: 

-  DA  T  AF  L  E  X  from  Data  Access  Carp.,  Miami,  1  L 

d BASE  II,  III  from  Ashton -Tate,  Culver  City,  CA 

-  INFORMIX  from  Relational  Database  Systems,  Sunnyvale,  CA 

-  MAG/base  III  from  Micro  Applications  Group,  Carioya  Park  CA 
MDBS+QRS  from  Micro  Data  Base  System  Inc.,  Lafayette,  IN 

-  OPTIMUM  from  Uveon ,  Denver,  CO 

-  ORACLE  from  Oracle  Corp,  Menlo  Park,  CA 

Q  PRO-4  from  Quick  n  Easy  Products,  Langhorne,  PA 
R:BASE  from  Microrim,  Bellevue,  WA 

-  REVELATION  from  Cosmos,  Seattle,  WA 

-  UNIT  V  from  Unify  Corp.,  Portland,  OR 

c .  Hardware 

As  described  in  the  feasibility  study  the  micro¬ 
computer  solution  is  the  only  acceptable  one  for  the  current 
a pp  1  icat.  :  on  . 

d .  Peop 1 e 

Currently  six  men  are  working  in  the  Soldier  Sec¬ 
tion  of  the  SCD  Personnel  Office  (a  captain,  two  sergeants  and 
three  soldiers).  None  of  these  needs  to  be  replaced  if  t  fie 
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current  system  is  maintained.  If  it  is  decided  to  implement 
a  database  system  using  a  microcomputer  then  at  least  four 
people  will  be  needed:  One  captain,  one  sergeant  and  two  sol¬ 
diers.  These  people  will  be  required  to  have  some  knowledge  of 
microcomputers . 

2 .  Select  one  Alternative 

After  the  evaluation  of  the  different  alternative 
solutions  and  in  agreement  with  the  results  and  constraints  of 
the  feasibility  study,  the  system  components  are  selected  as 
foil ows : 

a.  Data 

A  database  will  be  used  to  store  all  the  data  in 

the  system. 

b.  Software 

The  dBASE  III  Plus  package  was  chosen  as  the  DBMS. 
During  the  evaluation  process  a  number  of  other  DBMS  packages 
were  found  that  provide  almost  the  same  functions  as  dBASE  III 
Plus.  The  prices  of  these  packages  were  also  similar.  Some  of 
the  reasons  for  selecting  dBASE  III  Plus  are: 

-  Product  stability. 

dBASE  III  Plus  (was  dBASE  II  before)  has  been  in  the 
market  for  a  long  period  and  the  number  of  people  using 
it  is  continuously  increasing. 

-  Maintenance  support. 

There  are  many  enhancements  of  the  product  and  the  users 
interviewed  were  generally  satisfied  by  the  way  the  vendor 
responds  to  occurring  problems. 

-  Documentation  and  Training. 

The  documentation  is  very  well  written  and  readable. 
There  are  also  several  references  one  can  find  that  make 
the  learning  and  use  of  dBASE  III  Plus  easier. 


50 


The  dBASE  III  Plus  features,  limitations  and 
sof tware/hardware  requirements  are  described  below. 

dBASE  III  Plus  is  a  relational  DBMS  which  runs  on 
IBM  microcomputers  or  compatible  machines  and  stores  informa¬ 
tion  in  relational  data  tables. 

The  database  can  be  processed  in  two  ways.  One 
way  is  interactive  command  processing  in  which  the  data  in  the 
database  is  manipulated  by  means  of  commands  entered  interacti¬ 
vely  from  the  keyboard,  and  the  results  are  displayed  on  an 
output  device  such  as  a  monitor  or  a  printer.  A  second  way  is 
through  application  programs.  An  application  program  is  a 
collection  of  dBASE  III  Plus  commands  stored  in  a  file.  These 
programs  can  be  loaded  and  executed  by  the  DBMS.  This  capabi¬ 
lity  makes  dBASE  III  Plus  useful  for  application  development. 

The  database  files  used  by  dBASE  III  Plus  can  hold 
a  max imum  of : 

-  One  billion  records 

-  Two  billion  bytes 

-  4000  bytes  per  record 

-  128  fields  per  record 

-  254  bytes  per  field 

dBASE  III  Plus  allows  a  maximum  of  15  files  to  be 
open  at  once  including  database,  index,  memo,  procedure  and 
program  files.  This  sounds  like  a  serious  limitation  but  if 
the  application  programs  are  carefully  designed  these  problems 
can  be  avoided.  Note  that  this  limitation  is  imposed  by  PC_DQS 
and  not  by  dBASE  III. 

dBASE  III  Plus  is  designed  to  run  on  the  IBM  PC, 
IBM  PC  XT,  IBM  PC  AT  and  the  IBM-compatible  microcomputers . 
It  requires  MS_D0S  or  PC_D0S  version  2.0  or  later.  The  minimum 
memory  requirement  is  256  K  under  DOS  version  2.0  or  2.1. 
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dBASE  III  requires  more  memory  to  run  under  DOS  3.0  or  above 
and  if  you  want  to  replace  the  dBASE  III  program  editor  with 
an  external  editor  then  at  least  384  K  of  memory  will  be  requ¬ 
ired.  For  a  serious  application  development  the  microcomputer 
should  have  at  least  512  K  main  memory,  a  360  K  floppy  disk 
and  a  10  megabyte  hard  disk. 

c .  Hardware 

An  IBM  personal  computer  AT  with  a  20  Mbyte  hard 
disk  and  two  360  K  floppy  disks  is  recommended  for  implementa¬ 
tion.  Also  a  monitor  and  a  printer  will  be  used  as  output 
devices . 

d.  People 

□ne  captain,  one  sergeant  and  two  soldiers  with 
some  knowledge  of  computer  science  and  especially  on  micro¬ 
computers  will  be  required. 
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VII .  DETAILED  DESIGN 


A .  THEORY 

1 .  Purpose  of  the  Detailed  Design 

As  stated  before  the  purpose  of  the  Detailed  Design 
phase  is  to  determine  how  specifically  the  system  will  be 
imp 1 emen  ted . 

During  System  Design  the  solution  strategy  which  best 
satisfies  the  user's  requirements  was  selected.  If  this 
solution  involves  a  database  then  the  Detailed  Design  should 
be  divided  in  two  tasks:  The  Database  Design  and  the  Design  of 
the  Applications  Programs. 

2 .  Database  Design 

The  Database  Design  is  usually  divided  into  two  stages: 
Logical  Database  Design  which  is  entirely  independent  of  limi¬ 
tations  imposed  by  the  hardware  or  any  particular  DBMS  and 
Physical  Database  Design  which  is  dependent  on  the  DBMS  select¬ 
ed  during  System  Design. 

a.  Logical  Database  Design 

During  this  stage  the  database  logical  structure 
is  developed  by  determining  the  actual  contents  of  the  data¬ 
base  in  a  way  that  satisfies  the  user  requirements  without 
using  any  particular  DBMS. 

What  are  the  steps  that  should  be  followed  during 
logical  database  design?  Although  many  techniques  have  been 
defined,  unfortunately  once  again  there  is  no  algorithm  to 
follow.  David  Kroenke  in  his  book  "Database  Processing" 
[Ref.  9:  p.  177]  writes: 

"...  database  design  is  an  intuitive  and  artistic  process. 
There  is  no  algorithm  for  it.  Typically,  database  design  is  an 
iterative  process;  during  each  iteration  the  goal  is  to  get 
closer  to  an  acceptable  design..." 
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The  different  techniques  that  exist  for  logical 
database  design  vary  from  very  general  and  abstract  to  very 
detailed  techniques  that  focus  only  on  specific  aspects  of  the 
database  .  The  process  described  next  provides  a  simple  way  to 
create  a  logical  database  design  and  includes  the  major  steps 
found  in  most  techniques. 

First  the  data  to  be  stored  in  the  database  is 
identified.  Using  the  Data  Dictionary  ( DD )  prepared  during 
Analysis,  synonyms  are  identified.  Synonyms  are  two  or  more 
different  names  for  the  same  data  element.  It  is  desired  to 
remove  synonyms  from  the  database  in  order  to  eliminate 
ambiguity  and  redundancy.  For  this  reason  all  different  names 
of  the  same  data  element  are  replaced  with  one  standard  name, 
and  a  new  revised  version  of  the  Data  Dictionary  results. 

During  the  analysis  phase  every  data  element  that 

is  needed  by  the  system  was  recorded  in  the  DD.  Next  a  more 

detailed  examinaticn  of  the  DD  is  required  in  order  to  identi¬ 
fy  data  elements  that  cannot  be  part  of  the  database  or  must 

be  further  analyzed.  In  this  way  a  final  version  of  the  DD  is 

c  reated . 

The  next  step  in  the  logical  database  design  pro¬ 
cess  is  to  specify  the  logical  database  records.  By  examining 
the  DFD  of  the  system  the  data  stores  and  data  flows  which 
should  become  records  in  the  database  are  identified.  The  data 
elements,  alias  fields,  that  each  record  should  contain  are 
already  listed  in  the  DD.  Obviously  this  step  is  very  straight¬ 
forward  and  should  not  be  difficult  to  execute.  However,  some 
additional  items  must  be  acomplished.  One  is  to  determine 
which  records  should  be  combined  or  separated.  A  closer  exami¬ 
nation  of  the  process  descriptions  of  the  functional  require¬ 
ments  may  reveal  that  some  processes  utilize  only  a  small  part 
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of  the  information  stored  in  some  of  the  records.  Performance 
could  then  be  improved  by  breaking  such  records  into  more 
records  according  to  how  they  are  used  by  each  process.  In 
other  cases  two  or  more  records  should  be  combined  into  one 
if,  for  example,  they  are  used  simultaneously  by  most  proces¬ 
ses.  In  his  effort  to  determine  which  records  should  be  joined 
or  separated  the  system  designer  should  also  be  guided  by  the 
anticipated  future  use  of  the  records. 

Now  that  the  final  structure  of  the  database  has 
been  defined  one  final  item  is  required:  determine  the  primary 
key  for  each  record.  It  is  required  that  each  record  be 
uniquely  identified  in  any  of  the  files  in  the  database.  To  do 
this  one  or  more  of  the  fields  in  the  records  are  used  as 
identifiers.  These  fields  are  called  keys.  It  must  be  ensured 
that  a  selected  key  uniquely  identifies  a  record  and  this  is 
not  always  an  easy  job. 

b.  Physical  Database  Design 

This  stage  takes  the  logical  database  design  as 
its  input  and  transforms  it  into  a  form  that  is  acceptable  to 
the  hardware  and  to  the  Data  Base  Management  System  (DBMS) 
that  will  be  used. 

Since  this  transf orma tion  varies  greatly  from  one 
DBMS  to  another  it  is  not  possible  to  provide  a  general  des¬ 
cription  of  the  process.  In  order  to  be  able  to  perform  a 
physical  database  design  using  a  specific  DBMS,  the  designer 
should  study  its  documentation  first. 

3 .  Design  of  the  Application  Programs 

After  the  database  has  been  designed  the  next  step  is 
to  design  the  application  programs.  This  design  will  later 
result  in  code  using  the  Data  Manipulation  Language  ( DML ) 
provided  by  the  DBMS.  At  this  stage  we  work  independently  of 
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any  particular  programming  language,  designing  the  programs 
that  will  call  on  the  DBMS  in  order  to  provide  the  desired 
database  service. 

The  designer's  goal  is  to  identify  the  applications 
programs  and  then  develop  a  set  of  specifications  for  each 
program  that  will  contain  the  required  information  to  support 
writing  the  actual  code  during  the  next  stages  the  Implemen¬ 
tation. 

It  is  amazing  that  so  many  people  have  described  so 
many  different  program  design  techniques.  Terms  like  Modular 
design,  Top-down  design,  Bottom-up  design,  Structured  design, 
Stepwise  Refinement,  Systematic  Programming,  Transform  Analy¬ 
sis,  Transaction  Analysis  etc,  are  well  known  to  almost  every 
computer  science  student.  There  is  also  extensive  debate  as  to 
which  is  the  best  technique.  In  this  presentation  of  a  strate¬ 
gy  for  "design ing  application  programs  no  particular  design 
technique  will  be  fallowed  in  detail,  although  there  is  some 
similarity  with  Structured  Programming.  A  good  designer  should 
know  as  many  different  techniques  as  he  can  but  should  not 
commit  himself  to  only  one  of  them. 

The  programs  in  an  application  do  not  run  independent¬ 
ly  of  each  other.  One  program  is  usually  called  by  another  and 
either  during  or  after  execution,  passes  control  to  another 
program.  The  hierarchy  and  the  flow  of  control  among  the 
application  programs  of  a  system  can  be  represented  using  a 
Structure  Chart. 

A  structure  chart  is  a  pictorial  representation  that 
uses  simple  boxes  and  statements  to  describe  the  functions  in 
a  system.  To  illustrate  this  concept  Figure  7.1  shows  the 
structure  chart  for  a  very  simple  problem:  boil  an  egg.  Notice 
that  the  processing  flow  in  the  chart  is  from  left  to  right. 
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Also  note  that  all  subfunctions  are  grouped  under  a  main 
control  function. 


Figure  7.1  A  simple  Structure  Chart 

The  first  step  in  the  process  of  designing  the  appli¬ 
cations  programs  is  to  construct  a  Structure  Chart.  The  Data 
Flow  Diagram  of  the  analysis  stage  will  provide  all  the  infoi — 
mation  needed.  The  processes  in  the  DFD  will  become  programs 
in  the  Structure  Chart.  During  analysis  each  process  was 
decomposed  into  subprosesses  up  to  the  point  where  each  proc- 
ces  performed  only  one  single  task.  Therefore,  there  is  no 
need  for  further  decomposition  of  the  programs.  However,  these 
programs  must  be  grouped  under  control  programs  which  will 
determine  the  order  of  execution.  A  main  control  program  will 
be  on  top  of  the  other  control  programs. 

In  order  to  group  the  processes  under  common  control 
modules  automation  boundaries  are  drawn  in  the  DFD.  As  an 
example,  suppose  that  certain  processes  in  the  DFD  are  perfor — 
med  daily,  while  others  are  performed  weekly  or  monthly.  A 
line  is  drawn  to  surround  all  daily  processes  and  another  line 
for  the  weekly  or  monthly  processes,  thus  establishing  automa¬ 
tion  boundaries  in  the  DFD.  Care  must  be  taken  not  to  include 
in  the  same  automation  boundary  processes  with  timing  con¬ 
flicts.  Next  a  structure  chart  is  prepared  for  the  processes 
in  each  automation  boundary.  Finally,  by  connecting  all  these 
structure  charts  under  a  main  control  program,  a  structure 
chart  for  the  whole  system  is  realized. 
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In  order  to  make  the  reference  to  any  of  the  modules 
in  the  chart  simpler,  names  and  numbers  are  assigned.  It  would 
be  wise  to  use  names  that  conform  to  the  constraints  of  the 
programming  language  to  be  used.  Numbers  assigned  to  each  box 
in  an  orderly  fashion  facilitate  reference  even  more.  A  good 
method  for  assigning  numbers  to  modules  that  also  shows  the 
hierarchy  and  functional  dependence  among  the  modules  in  a 
structure  chart  is  described  below.  (A  full  description  of 
this  method  is  contained  in  [Ref.  23]). 

a.  Number  the  main  control  module  by  suffixing  a  digit  with 
as  many  zeros  as  the  number  of  subordinate  levels  in  the 
structure  chart.  In  the  example  in  Figure  7.2  there  are 
three  such  levels.  Therefore,  the  main  control  module 
should  be  numbered  "1000". 

b.  Assign  numbers  to  the  modules  in  a  subordinate  level  by 
incrementing  the  left-most  zero  digit  of  the  controlling 
module  by  one  proceeding  from  left  to  right. 

c.  Repeat  step  (b)  until  all  modules  have  been  assigned 
numbers . 


1000 


Level  1 


Level  2 


Level  3 


Figure  7.2  Numbering  the  modules  in  a  Structure  Chart 
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The  advantage  of  this  numbering  scheme  is  that  by 
knowing  the  number  of  a  module  one  can  tell  which  module 
invokes  it,  by  replacing  the  last  non-zero  digit  with  a  zero. 
For  example  module  1312  is  called  by  module  1310,  which  in 
turn  is  called  by  module  1300  which  is  finally  called  by 
module  1000.  Therefore  it  is  easy  to  construct  the  structure 
chart  by  simply  knowing  the  numbers  of  all  the  modules. 

The  weakness  of  this  method  is  that  it  cannot  be 
applied  if  a  certain  module  in  the  system  invokes  more  than 
nine  other  modules,  an  occurence  that  is  very  unusual  for 
small  and  medium  systems. 

The  second  step  in  the  design  of  the  application 
programs  is  to  create  a  table  that  contains  a  brief  descri¬ 
ption  of  each  module  in  the  structure  chart.  This  table  is 
usually  called  Visual  Table  of  Contents  or  VT0C  and  serves  as 
a  quick  reference  guide  when  someone  wants  to  know  the  purpose 
of  a  program. 

Finally  the  third  step  is  to  document  the  programs  in 
the  structure  chart  by  creating  an  IPO  ( Input/Dutput/Process ) 
chart  for  each  program.  As  its  name  implies,  the  IPO  chart  of 
a  module  shows  the  inputs  to,  outputs  from  and  the  process 
performed  by  the  module.  The  data  stores  and  flows  shown  in 
the  DFD  are  the  sources  of  the  inputs  and  outputs.  The  algo¬ 
rithm  descriptions  of  the  Functional  Specification  will  be 
used  to  document  the  process.  To  describe  the  process  steps 
on  each  IPO  chart  Structured  English,  pseudocode,  or  a  flow¬ 
chart  may  be  used. 

The  system  Structure  Chart,  the  VT0C  and  the  IPO 
charts  produced  during  this  stage  provide  an  increasing  level 
of  detail  and  together  they  constitute  a  complete  design  of 
the  applications  programs. 
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B.  IMPLEMENTATION  OF  THE  DETAILED  DESIGN 


1 .  Database  Design 

a.  Logical  Database  Design 

(1)  Identify  the  data  to  be  stored 

The  process  is  initiated  with  the  Data  Dictio¬ 
nary  (DD)  constructed  during  analysis.  A  summary  of  all  the 
data  items  described  in  the  DD  is  shown  in  Figure  7.3  (for  the 
moment  do  not  consider  the  last  three  columns).  Each  data 
element  is  now  examined  in  detail. 

First  synonyms  are  identified.  One  example  is 
the  data  elements  UNIT  NAME,  UNIT,  UNIT  ASSIGNED  TO,  and 
ASSIGNED  UNIT,  found  in  the  data  stores  D5,  D8 ,  D6  and  D4 , 
respectively,  which  are  in  fact  the  same  data  element  under 
different  names.  The  term  UNIT  is  chosen  to  be  the  common  name 
and  a  reference  number  is  entered  in  the  column  SYNONYMS. 
Similarly  DATE  ASSIGNED  of  D4  and  DATE  OF  REPORT  of  D6  can  be 
represented  as  one  element.  The  remainder  of  the  data  elements 
in  the  DD  are  similarly  analyzed.  The  result  of  this  work  is 
shown  in  the  column  SYNONYMS  in  Figure  7.3. 

Next  data  that  cannot  be  included  in  the  data¬ 
base  are  considered.  For  example,  consider  the  data  element 
TOTAL  NUMBER  OF  ENLISTED  of  data  store  D1 .  It  is  undesirable 
to  include  this  element  in  every  record  in  D1 .  Unfortunately, 
the  relational  model  does  not  allow  records  of  variable  length. 
The  solution  is  to  create  a  separate  file  or  to  ask  the  user 
to  enter  this  information  when  needed.  The  second  solution  is 
prefered  and  the  DELETE  column  for  this  element  is  marked. 

Data  that  must  be  analyzed  are  considered  next. 
For  example,  SOLDIER  NAME  is  a  data  element  consisting  of 
three  subfields:  FIRST  NAME,  MIDDLE  INITIAL  and  LAST  NAME. 
This  structure  is  not  allowed  by  the  relational  model. 
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Therefore,  this  element  is  divided  into  three  data  elements 
and  the  ANALYZE  column  in  the  DD  is  marked. 
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Figure  7.3  The  data  items  of  the  Data  Dictionary 
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Finally,  the  type  and  width  of  each  data 
element  is  considered.  Why  should  FAMILY  SUPPORTER  be  a 
three-byte  character  field  instead  of  an  one-byte  logical 
field?  Or  the  MARITAL  STATUS  field  can  be  changed  to  an 
one-byte  character  field  which  will  store  M  for  Married,  D  for 
Divorced,  S  for  Single  and  W  for  Widowed  provided  that  a  short 
explanation  is  given  to  the  user  on  the  screen  when  he  runs 
the  program.  Also,  there  is  no  need  for  I D_NUMBER  to  be  a 
numeric  field  since  there  are  no  arithmetic  computations 
performed  on  it.  A  character  field  occupies  less  memory  space 
and  can  be  manipulated  much  faster  than  a  numeric  field.  A 
summary  of  the  Data  Dictionary  is  shown  in  Figure  7.4. 

(2)  Specify  the  logical  database  records 

Each  data  store  in  the  DFD  will  normally  be 
transformed  into  a  database  file.  The  data  elements  of  each 
file  are  shown  in  the  Data  Dictionary  in  Figure  7.4.  What 
files  should  be  combined  or  separated?  To  determine  this  the 
chart  in  Figure  7.5  will  be  utilized.  This  chart  shows  which 
data  items  of  each  data  store  are  used  by  each  process.  For 
example  process  P2.1  uses  the  ID_NUMBER  of  both  data  store  D1 
and  D4 .  With  the  help  of  this  chart  consider  data  store  D4 
which  is  the  largest  data  store  in  the  system.  D4  also  con¬ 
tains  more  records  than  any  other  data  store.  This  means  that 
significant  memor/  space  will  be  occupied  by  D4  and  therefore, 
the  process  of  loading  it  will  take  considerable  time.  On  the 
other  hand  observe  that  some  of  the  processes  make  use  of  only 
a  small  part  of  this  data  store.  For  example,  process  P4 . 3 
only  uses  the  names  of  the  three  units  of  preference.  After 
carefully  looking  at  all  processes  it  is  decided  that  data 
store  D4  should  be  divided  into  four  data  stores  as  shown  in 
Figure  7.6. 
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s/1 

DATA  I  L  K  1  (  1  T 

TYPE 

IIPTI 

DATA 

S  T  0  I  I 

1 

2  3 

A 

5 

s 

7 

8 

9  10  11  12  13  14 

1 

ID  ROBBER 

CHAR 

7 

4 

4 

4 

4 

4 

4 

4  4  4 

2 

FIRST  PARE 

CHAR 

15 

4 

4 

4 

4 

4 

4 

4 

3 

LAST  RAKE 

CHAR 

20 

4 

4 

4 

4 

4 

4 

4 

4 

RIDDLE  INITIAL 

CBAR 

1 

* 

4 

4 

4 

4 

4 

4 

5 

DATE  ERLISTED 

DATE 

8 

4 

4 

4 

6 

SERVICE  D0RATI0H 

ROBEFIC 

2 

4 

4 

4 

7 

CLASS 

CBAR 

3 

4 

4 

4 

8 

MARITAL  STATDS 

CBAR 

1 

4 

4 

4 

9 

ROBBER  OF  CHILDREN 

BOBERIC 

1 

4 

4 

4 

10 

FINANCIAL  STATUS 

CBAR 

1 

4 

4 

4 

11 

FAULT  SOPPORTEF 

LOGICAL 

1 

4 

4 

4 

12 

ROMBEF  OF  BROTHERS  IR  SERVICE 

PUHERIC 

1 

4 

4 

4 

13 

SPECIAL  REASONS  FOR  TRANSFER 

LOGICAL 

1 

4 

4 

4 

14 

PREFERED  ORIT  1 

CHAR 

7 

4 

4 

4 

IS 

PREFEBED  ORIT  2 

CHAR 

7 

4 

4 

4 

16 

PREFERED  ORIT  3 

CBAR 

7 

4 

4 

4 

17 

STREET 

CBAR 

15 

4 

4 

4 

4 

18 

CITT 

CBAR 

20 

4 

4 

4 

4 

19 

STATE 

CBAR 

15 

4 

4 

4 

4 

20 

ZIP 

CBAR 

5 

4 

4 

4 

4 

21 

PHONE 

CHAR 

14 

4 

4 

4 

4 

22 

SPECIALTY 

CBAR 

8 

4  4 

4 

4 

4 

4 

4  4  4  4  4 

23 

REQUIRED  SOLDIERS  FOR  SPECIALTY  TRAIRIRG 

NOBERIC 

4 

4 

24 

ORIT 

CBAR 

7 

4 

4 

4 

4 

4  4 

25 

DATE  ASSIGRED 

DATE 

mm 

4 

4 

26 

COKPLITED  TRAIRIRG 

LOGICAL 

n 

4 

27 

DATE  RiER  REMAINING  SERVICE  <  4  KOR. 

DATE 

H 

4 

28 

REQOIRED  ROKBER  OF  SOLDIERS 

XUBERIC 

3 

4 

29 

EXISTING  ROKBER  OF  SOLDIERS 

ROBERIC 

3 

4 

30 

COKPLEHERT  ROKBER  OF  SOLDIERS 

EOKERIC 

3 

4 

31 

DATE  RETIRED 

DATE 

8 

4 

4 

32 

QOALIFICATIOR  POIRTS 

ROBERIC 

3 

4 

33 

REEDS 

PORERIC 

3 

4 

Figure  7.4  A  summary  of  the  Data  Dictionary 


Another  use  of  the  chart  in  Figure  7.5  is  to 
help  determine  which  fields  are  redundant.  For  example,  the 
FIRST  NAME,  LAST  NAME  and  MIDDLE  INITIAL  fields  can  be  removed 
from  data  stores  D3 ,  D6  and  D8  since  no  process  uses  these 
fields  . 
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30  COHPLEMKKT  E0»8  OF  SOLDIERS  5 

31  DATE  RETIRED  8 

32  «04LIP1CAT10H  POIETS  1 

33  REEDS  i; 


FIELD  NAME 

Original 

Data 

Store 

D4 

NEW  DATA  STORES 

D4.1 

D4.2 

D4.3 

D4.4 

ID  NUMBER 

4 

4- 

4- 

+ 

4 

FIRST  NAME 

4 

4 

LAST  NAME 

+ 

4 

MIDDLE  INITIAL 

4 

4- 

DATE  ENLISTED 

4 

+ 

SERVICE  DURATION 

+ 

4- 

CLASS 

4- 

4 

MARITAL  STATUS 

4* 

4 

NUMBER  OF  CHILDREN 

4- 

4 

FINANCIAL  STATUS 

+ 

4 

FAMILY  SUPPORTER 

4- 

4 

NUMBER  OF  BROTHERS  IN  SERVICE 

4- 

4 

SPECIAL  REASONS  FOR  TRANSFER 

+ 

4 

PREFERED  UNIT  1 

4- 

4 

PREFERED  UNIT  2 

4- 

4 

PREFERED  UNIT  3 

4 

4 

STREET 

4- 

4- 

CITY 

4- 

4- 

STATE 

4“ 

4* 

ZIP 

4- 

4- 

PHONE 

4- 

4 

SPECIALTY 

4- 

4 

UNIT 

4- 

4 

DATE  ASSIGNED 

+ 

4 

COMPLETED  training 

4- 

4 

DATE  WHEN  REMAINING  SERVICE  <  4  MON 

4- 

4 

Figure  7.6  The  analysis  of  Data  Store  D4 


Next,  standard  names  are  given  to  the  files 
and  the  data  elements.  Although  this  step  in  the  design  is 
guite  independent  of  any  particular  DBMS,  it  will  save  time  if 
while  naming  the  files  and  data  elements,  consideration  is 
given  to  the  selected  DBMS,  dBASE  III  Plus,  which  allows  eight 
characters  for  record  names  and  ten  characters  for  field  names. 
The  data  stores  and  the  corresponding  database  files  are  shown 
in  Figure  7.7. 

Next  the  key  field  for  each  record  must  be 
determined.  Most  of  the  records  in  the  data  base  contain  an 
ID_NUMBER  field,  which  is  an  excellent  identifier  of  the 
record .  In  the  few  records  that  do  not  have  an  ID_NUMBER,  the 
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S/N 

DATA  STORE 

FILE  NAME 

1 

D1 

ENLISTED 

2 

D2 

TRAIN  RQ 

3 

D3 

COMPL  TR 

4 

D4 . 1 

SLD  AtfDR 

5 

D4.2 

SLD  SERV 

6 

D4.3 

SLD  TRAN 

7 

D4.4 

SLD  PREF 

8 

D5 

UNIT  ORG 

9 

D6 

ASSIGNMS 

10 

D7 

CHANGES 

11 

D8 

RETIRED 

12 

D9 

SPECS 

13 

DIO 

HISTORY 

14 

Dll 

TRSF  PTS 

15 

D12 

UNIT  REQ 

16 

D13 

UNITS 

17 

D14 

TRAINEES 

Figure  7.7  Naming  the  database  files 

UNIT,  SPECIALTY  or  a  combination  of  these  two  fields  was 
selected  as  a  key.  Figure  7.8  shows  the  final  structure  of 
the  database.  A  circled  cross  denotes  that  this  field  is  a 


Now  that  the  logical  structure  of  the  database 
has  been  defined  the  memory  space  that  each  field  and  each 
record  will  occupy  can  be  determined.  The  maximum  number  of 
records  that  each  database  file  may  contain  is  also  known 
Therefore,  the  memory  space  needed  for  each  file  and  consequ¬ 
ently  for  the  whole  database  can  be  calculated.  This  calcula¬ 
tion  is  shown  in  Figure  7.9. 

b.  Physical  Database  Design 

The  logical  database  sructure  defined  during  the 
previous  step  will  now  be  transfered  into  a  physical  structure 
This  means  that  the  actual  database  will  be  created  and  its 
structure  stored  on  a  computer  storage  device,  such  as  a  disk, 
using  the  DBMS  software  package  that  has  been  selected,  namely 
dBASE  III  Plus. 
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FIELD  NAME 

TYPE 

WIDTH 

ENLI  STED 

TRAI N-RO 

COMPL-TR 

SLD-ADDR 

SLD-SERV 

SLD-TRAN 

SLD-PREF 

UNI T-ORG 

ASSIGNMS 

CHANGES 

RET  1  RED 

SPECS 

HISTORY 

trsf-pts 

unit-red 

UNITS 

TRAINEES 

1 

ID  NUMBER 

CHAR 

7 

©  ©©©©©  ©@©  ©©  0 

2 

F  NAME 

CHAR 

15 

4-  4-  *4-  4- 

3 

L  NAME 

CHAR 

20 

+  +  +  + 

4 

M  INITIAL 

CHAR 

1 

+  +  +  + 

5 

DATE  ENL 

DATE 

8 

4-  4-  + 

6 

SERV  DUR 

NUMERIC 

2 

+  +  + 

7 

CLASS 

CHAR 

3 

+  +  + 

8 

MARIT  STAT 

CHAR 

1 

+  +  + 

9 

NUM  CHILD 

NUMERIC 

1 

+  +  + 

10 

FINAN  STAT 

CHAR 

1 

4-  4-4- 

11 

FAM  SUPP 

LOGICAL 

1 

+  +  + 

12 

BROTH  SERV 

NUMERIC 

1 

4-  4-  + 

13 

SPEC  REAS 

LOGICAL 

1 

+  +  + 

14 

PRF  UNIT1 

CHAR 

7 

+  +4* 

15 

PRF  UNIT2 

CHAR 

7 

+  4-4- 

16 

PRF  UNIT3 

CHAR 

7 

+  4-4- 

17 

STREET 

CHAR 

15 

4-4-  4-4- 

18 

CITY 

CHAR 

20 

4-4-  4-4- 

19 

STATE 

CHAR 

15 

4-4-  4-4- 

20 

ZIP 

CHAR 

5 

4-4-  4-4- 

21 

PHONE 

CHAR 

14 

4-4-  4-4- 

22 

SPECIALTY 

CHAR 

8 

& +  +  (i)+  (l)++(i)  + 

23 

SPEC  REO 

NUMERIC 

+ 

24 

UNIT 

CHAR 

+  © 4  0© 

25 

DATE  ASIGN 

DATE 

4"  4* 

26 

END  TRAIN 

LOGICAL 

4- 

27 

DATE  4 

DATE 

8 

4- 

28 

REQUIRED 

NUMERIC 

3 

4- 

29 

EXISTING 

NUMERIC 

3 

4- 

30 

COMPLEMENT 

NUMERIC 

3 

4- 

31 

DATE  RET 

DATE 

8 

4-  4- 

32 

Q'  'AL  PTS 

NUMERIC 

3 

4- 

33 

Nut  DS 

NUMERIC 

3 

4- 

Figure  7.8.  The  final  structure  of  the  database. 


Creating  a  database  using  dBASE  III  Plus  is  very 
easy  and  is  done  by  using  the  CREATE  command.  The  database 
file  ASSIGNMS  is  created  as  an  example: 

-  First  bring  up  dBASE  III  by  typing: 

C>  DBASE 

-  When  the  period  prompt  is  received  enter  the  command 
CREATE  followed  by  the  file  name: 

.  CREATE  ASSIGNMS 
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TRAINEES 


dBASE  III  Plus  will  then  ask  for  the  field  name,  type  and 


width  and  if  it  is  a  numeric  field,  the  width  of  the 
decimal  part.  Since  this  information  has  been  defined  in 
the  logical  design,  it  can  easily  be  entered. 


RECORD 

MAXIMUM 

MAXIMUM 

FILE  NAME 

SIZE 

NUMBER 

FILE  SIZE 

NOTES 

( Bytes ) 

OF  RECORDS 

( Bytes ) 

ENLISTED 

153  (a) 

1 , 500 

229,500 

(a)  One  byte  is  used 

TRAIN  RQ 

13 

10 

130 

as  a  flag  by  dBASE 

COMPL  TR 

16 

1,100  (b) 

17,600 

III  Plus 

SLD  ADDR 

113 

16,500  (c) 

1,864,500 

(b)  400  soldiers  comp- 

SLD  SERV 

53 

16 , 500 

874 , 500 

lete  training  in 

SLD  TRAN 

14 

16 , 500 

231,000 

1  month 

SLD  PREF 

29 

16 , 500 

478,000 

(c)  1500  $  11  classes 

UNIT  ORG 

25 

300  (d) 

7,500 

(d)  10  spec  *  30  units 

ASSIGNMS 

31 

1  ,  100 

34 ,100 

(e)  no  more  than  27.  of 

CHANGES 

142 

330  (e) 

46,860 

all  sol diers 

RETIRED 

16 

1 , 500 

24,000 

(f)  Removed  from  data- 

SPECS 

9 

10 

90 

base  once  every 

HISTORY 

140 

9,000  (f) 

1 ,260,000 

year  . 

TRSF  PTS 

19 

1  ,  100 

20,900 

UNIT  REQ 

19 

300 

5,700 

UNITS 

8 

30 

240 

TRAINEES 

16 

10 

160 

MAXIMUM  DATABASE  SIZE 

5,095,180 

Figure  7.9  Memory  requirements  of  the  database 


The  file  ASSIGNMS  as  entered  in  the  computer  is 
shown  in  Figure  7.10 


Field  Name 

Type 

Width 

1  . 

I D_NUMBER 

c harac  ter 

7 

2. 

SPECIALTY 

c  harac  ter 

3 

3. 

UNIT 

c  harac  ter 

7 

4  . 

DATE_AS  IGN 

date 

8 

Figure  7.10  File  ASSIGNMS 

Working  in  the  same  way  the  remaining  files  in  the 
database  are  created. 
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2. 


The  design  of  the  programs  that  will  be  used  by  the 
DBMS  to  process  the  data  in  the  database  is  the  next  step. 
According  to  the  method  previously  described,  the  DFD  of 
analysis  must  be  transformed  into  a  structure  chart. 

The  first  step  is  to  identify  automation  boundaries 
for  the  processes  in  the  DFD.  For  example,  consider  process 
P2.1  which  adds  new  records  in  data  store  D4  for  the  new 
enlisted  soldiers.  What  other  processes  could  be  inside  the 
same  automation  boundary  with  P2.1?  Process  P2.1  uses  as  input 
data  store  D1  (New  Enlisted  Soldiers)  which  is  being  updated 
by  process  P5.4  (Get  Enlisted  Soldiers  data).  Therefore,  P5.4 
and  P2 . 1  can  be  included  in  the  same  boundary  but  it  must  be 
assumed  that  P5.4  will  be  executed  first.  Next  the  other 
processes  are  considered,  and  after  having  examined  each  one 
of  them,  the  grouping  of  all  processes  in  the  DFD  into  automa¬ 
tion  boundaries  is  produced  as  shown  in  Figure  7.11. 


TIME 

PROCESS 

1st  of  each  month 

P5.1,  P3.1,  P2.3,  P5.3,  P2.2.3 

2nd  of  each  month 

P4.1,  P4.2,  P4.3,  P3.2,  P2.2.2,  P6 . 2 

3rd  of  each  odd  month 

P5.4,  P2.1 

10th  of  each  odd  month 

PI,  P6.1 

24th  of  each  month 

P5.2,  P5.5,  P2.2.1 

Figure  7.11  Automation  boundaries 


For  each  one  of  these  boundaries  a  structure  chart  is 
constructed.  On  the  top  of  each  chart  a  control  module  is 
inserted,  which  controls  the  flow  of  execution  among  the 
processes.  Inside  the  boxes  of  the  structure  charts  a  very 
brief  imperative  statement  is  provided  which  explains  the 
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purpose  of  the  module.  The  result  of  this  work  is  shown  in 
Figures  7.12  through  7.16. 


Figure  7.12  Structure  chart  for  the  processes: 

P5.1,  P3.1,  P2.3,  P5.3  AND  P2 . 2 . 3 


Figure  7.13  Structure  chart  for  processes: 

P4.1,  P4.2,  P4.3,  P3.2,  P2 . 2 . 2  and  P6 . 2 


The  system’ s  structure  chart  is  almost  complete.  The 
only  thing  remaining  is  to  connect  all  structure  charts  under 
a  main  control  module  and  number  and  name  the  modules  in  the 
chart.  Figure  D.l  in  Appendix  D  shows  the  completed  structure 
char t . 
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a 


Figure  7.14  Structure  chart  for  processes  P5.4  and  P2.1 


Figure  7.15  Structure  Chart  for  processes  Pi  and  P6.1 


Figure  7.16  Stucture  chart  for  processes  P5.2,  P2.2.1  and  P5.5 


The  next  step  is  to  prepare  a  table  that  contains  a 
brief  description  of  the  function  of  each  module  in  the  stru¬ 
cture  chart.  This  table  gives  some  additional  information 
and  helps  in  clarifying  some  of  the  imperative  statements  in 
the  boxes  of  the  structure  chart.  The  second  ingredient  of  the 
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program  design,  the  VTOC 
Append i x  D ) . 


is  now  complete  (see  Figure  D.2  in 


Finally  the  IPO  charts  are  prepared ,  one  for  each  box 
in  the  structure  chart.  These  charts  provide  detailed  informa¬ 
tion  on  the  inputs  that  each  module  requires,  the  process 
performed  by  the  module  and  the  outputs  produced. 

When  constructing  an  IPO  chart,  most  designers  prefer 
to  use  Structured  English  to  describe  the  process  performed  by 
a  module.  Others  prefer  to  use  pseudocode,  or  logic  flowcharts 
or  a  combination  of  these  techniques. 

The  logic  flowchart  provides  an  excellent  way  for 
describing  the  steps  of  a  process.  It  uses  very  few,  simple 
symbols  and  is  easy  to  follow.  Many  people,  however,  consider 
flowcharts  as  a  bad  choice.  The  reason  is  that  flowcharts  have 
been  misused  for  many  years.  Programmers  in  the  past  were 
usually  required  to  document  their  programs  using  flowcharts. 
Whai  they  really  were  doing  was  writing  the  program  first  and 
then  drawing  a  flowchart  that  echoed  the  program  code.  Another 
reason  why  flowcharts  are  not  very  popular  is  that  they  are 
difficult  to  construct  if  the  program  is  very  complex.  For  the 
DBMS  considered  in  this  thesis,  the  processes  of  the  system 
have  been  decomposed  to  the  level  where  each  module  performs 
only  one  function.  Therefore,  logic  flowcharts  are  prefered 
for  the  IPO  charts  to  show  the  process  performed  by  each 
program.  The  IPO  charts  for  all  twenty  seven  modules  of  the 
system  structure  chart  are  shown  in  Figures  D.3.1  through 
D.3.27  of  Appendix  D. 

The  Structure  chart  together  with  the  VTQC  and  the  IPO 
charts  form  the  design  specifications  of  the  applications 
programs.  This  design  will  be  translated  into  source  code 
during  the  Implementation  phase. 
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VIII.  IMPLEMENTATION 


A .  THEORY 

1 .  The  Purpose  of  the  Implementation  Phase 

This  phase  is  probably  the  largest  and  most  difficult 
one.  It  may  fail  if  the  phases  preceding  it,  especially  the 
Analysis  and  Design  phases,  have  not  been  adequately  document¬ 
ed.  If,  however,  these  two  phases  have  been  successfully 
completed,  the  implementation  phase  will  be  straightf orward . 

The  purpose  of  the  Implementation  phase  is  primarily 
to  deliver  a  system  ready  for  execution.  The  two  major  tasks 
accomplished  during  this  phase  ares 

-  To  take  the  design  spec i f ica tions  that  resulted  from  the 
Detailed  Design  phase  and  translate  them  into  source  code. 

-  To  verify  that  this  source  code  implements  correctly  the 
design  specifications. 

2 .  The  steps  of  Implementation 

The  steps  that  must  be  followed  during  this  stage  are: 

a.  Construct  a  test  database 

During  the  design  phase  the  database  is  created 
by  defining,  compiling  and  storing  its  structure  using  the 
DBMS  previously  selected.  This  database,  however,  contains 
no  real  information.  The  purpose  of  constructing  a  test 
database  is  twofold:  to  test  the  accuracy  of  the  database 

definitions  and  to  facilitate  the  testing  of  the  application 
prog  rams . 

b.  Code  the  application  programs 

During  this  step  the  detailed  design  specificati¬ 
ons  are  transformed  into  source  code.  The  first  consideration 
is  the  order  of  program  development.  In  other  words  it  must  be 
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decided  which  programs  to  develop  first.  There  are  two  appro¬ 
aches  used  by  the  majority  of  the  programmers:  the  top-down 
and  the  bottom-up  approach. 

During  top-down  program  development  the  programmer 
starts  with  the  main  application  program  and  works  down 
through  the  system  structure  chart,  leaving  for  last  the 
programs  at  the  bottom  of  the  chart.  To  test  a  finished 
program  at  a  higher  level,  the  programmer  creates  dummy  subpro 
grams  that  simulate  the  lower  level  programs  called  by  the 
higher  level  program.  These  programs  are  called  stubs. 

During  bottom-up  development  the  programmer  starts 
with  the  programs  at  the  lowest  level  which  do  not  depend  on 
any  other  program  in  the  system.  When  all  the  independent 
programs  have  been  developed  and  tested,  the  programmer  moves 
to  the  programs  that  call  them.  Using  this  approach  no  dummy 
subprograms  are  necessary. 

c.  Test  the  system 

To  test  the  coded  programs  the  test  database  is 
used.  First  each  program  is  tested  independently,  refered  to 
as  a  unit  test.  Finally  the  system  programs  as  a  whole  are 
tested  which  is  called  integrated  test.  Both  unit  and  integra¬ 
ted  testing  are  difficult  tasks.  Each  program  should  be  tested 
for  its  handling  of  abnormal  situations  and  data  entry  errors, 
attempting  to  use  the  system  as  the  users  will.  Typical  use 
cycles  should  be  exercised  to  make  sure  that  the  programs  work 
together  as  they  were  designed.  Next,  check  the  data  files  to 
see  if  the  application  adds,  updates  and  deletes  data  properly 
No  matter  how  much  time  is  spent  on  testing,  it  cannot  be 
overdone.  Therefore  it  must  be  decided  when  sufficient  testing 
has  been  done  to  ensure  that  the  system  is  not  going  to  crash 
after  it  is  up  and  running. 


d.  Document  the  system 

The  user's  opinion  of  a  system  is  greatly  influen¬ 
ced  by  the  quality  of  the  documentation  he  is  given  and  the 
ease  with  which  he  can  use  this  documentation .  Documentation 
helps  the  user  to  maintain  the  system.  Users  must  be  able  to 
read  and  understand  the  documentation  in  order  to  correct  or 
modify  an  application  program.  Well  documented  programs  are 
easier  to  maintain  but  incorrect  and/or  out  of  date  documen¬ 
tation  is  worse  than  none  at  all. 

Well  designed  and  carefully  formatted  code  is  the 
start  of  a  properly  documented  system.  Document  the  programs 
considering  the  people  who  will  have  to  maintain  the  applica¬ 
tion.  Maintenance  personnel  do  not  trust  documentation  that  is 
not  embedded  in  the  code  or  otherwise  "on  line".  Program 
documentation  starts  with  the  program-header  and  includes 
comment  lines  and  line-by-line  comments  adjacent  to  the 
program  commands  and  statements. 

The  program  header  provides  the  name  of  the 
program,  a  description  of  what  it  does,  the  date  of  the  last 
update  and  optionally  the  significance  of  each  program  para¬ 
meter  . 

Comment  lines  are  used  to  describe  the  function 
of  a  group  of  statements.  Usually  a  well  documented  program 
includes  a  comment  line  for  each  box  in  the  program  flowchart. 
Line-by-line  comments  document  exactly  what  each  line  of 
program  code  is  doing. 

To  complete  the  documentation,  in  addition  to 
"on  line"  documentation: 

(1)  Document  procedures  for  the  user  on  how  to: 

.  Use  the  new  system 

.  React  in  case  that  the  system  fails 
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(2)  Document  procedures  for  the  operations  personnel  on 
how  to: 

.  Act  on  a  system  failure 
.  Back-up  the  data  base 

e.  Train  users  and  operations  personnel 

Although  the  documen ta t i on  given  to  the  user  and 
the  operations  personne'  provides  information  on  how  to  in¬ 
stall,  operate  and  check  out  the  system,  some  training  of 
personnel  is  required.  Training  will  help  them  to  understand 
the  documentation,  answer  the  questions,  and  clarify  misunder¬ 
stand  i ngs  . 

f.  Test  the  new  system  in  parallel  with  the  old  one 
If  possible,  the  new  system  should  be  run  in  paral 

lei  with  the  old  one.  In  this  way  the  transition  becomes 
smoother  and  a  comparison  of  the  results  of  the  two  systems 
can  be  made. 

B.  IMPLEMENTATION 

1 .  Constructing  a  test  data  base 

The  data  base  consists  of  17  files  which  were  created 
during  the  Detailed  Design  phase.  The  next  step  is  to  enter 

data  in  these  files  to  facilitate  the  testing  of  the  applica¬ 
tion  programs.  Using  dBASE  III  Plus  is  very  easy  to  add 

records  to  a  data  base  file  and  fill  them  with  information 

using  the  following  commands: 

-  USE  <file  name> 

-  APPEND 

A  single  blank  record  will  be  displayed  on  the  screen 
and  the  user  can  fill  in  the  empty  fields.  After  the  last 
field  has  been  entered  the  user  enters  a  <Pg  Dn >  and  a  new 
blank  record  is  displayed.  When  finished  the  user  presses 


<Esc>  to  terminate  the  addition  process.  All  data  base  files 
do  not  require  initial  loading.  Some  of  these  files  are  loaded 
by  the  system.  For  example,  test  data  is  not  required  for  the 
ASSIGNMS  file  or  the  RETIRED  file.  This  is  done  by  the 
ASSIGNMT  and  GET-RET  programs,  respectively.  The  files  in 
which  test  data  is  entered  will  be: 

SLD-ADDR,  SLD-SERV,  SLD-TRAN ,  SLD-PREF ,  UNIT-QRG,  SPECS, 
HISTORY  and  UNITS.  Manual  lists  must  also  be  prepared  for  NEW 
ENLISTED  soldiers,  soldiers  who  COMPLETED  SPECIALTY  TRAINING, 
CHANGES  in  soldiers  status  and  soldiers  currently  in  TRAINING. 

2 .  Translating  the  design  into  dBASE  III  Plus  code 

The  IPO  charts  and  the  logic  flowcharts  of  the 
Detailed  Design  contain  enough  information  to  fully  capture 
the  program  logic.  Therefore  the  effort  to  translate  each  step 
in  the  flowcharts  into  one  or  more  dBASE  III  commands  is  a 
straightf orward  process. 

As  mentioned  before  there  are  two  different  approaches 
to  program  development:  bottom-up  and  top-down.  It  is  the 
author's  opinion  that  the  bottom-up  approach  is  easier  to 
follow  since  the  program  can  be  tested  immediately  after 
writing  it,  instead  of  having  to  create  "stubs"  as  in  the 
top-down  approach. 

The  listings  for  the  programs  PERS-MGT ,  ENL-SLDS, 
GET-ENL  and  ADD-SLD  are  shown  in  Appendix  E  (Sections  E.l 
through  E . 4  )  . 

3 .  Testing,  debugging  and  documenting  the  system 

Using  the  test  data  base  constructed,  the  application 
programs  are  tested  and  debugged  individually.  Finally  the 
system  as  a  whole  is  tested. 
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The  listing  of  program  PERS-MGT  (Section  E.l  in  Ap¬ 
pendix  E)  provides  an  example  of  "on-line"  documentation.  Each 
programmer  can  use  his  own  skills  to  create  good  and  readable 
documen  tat ion . 
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IX.  CONCLUSION 


The  steady  decline  in  computer  hardware  costs  not  only 
makes  it  possible  to  add  more  applications  on  computers  but 
it  also  distributes  computing  power  to  more  and  more  new 
users.  As  a  result  the  demand  for  software,  that  tells  the 
computer  exactly  what  steps  to  perform  to  convert  its  raw 
power  into  useful  operations,  is  increasing  steadily. 

Therefore,  improved  techniques  in  software  development 
become  the  key  issue  if  further  expansion  of  the  use  of 
computers  is  to  be  achieved.  Software  engineering  is  rapidly 
emerging  as  a  discipline  for  managing  the  development  of 
software  systems,  but  like  every  new  engineering  discipline 
has  not  yet  achieved  widespread  acceptance. 

Due  to  the  existing  shortage  in  software  engineers,  a 
large  number  of  people  are  building  software  systems  who  have 
limited  or  no  knowledge  of  the  software  engineering  principles. 
In  fact  most  of  them  have  obtained  only  a  technical  knowledge 
of  one  or  two  programming  languages  and  one  or  two  computer 
systems . 

This  thesis  is  intended  especially  for  these  people. 
Fundamental  software  engineering  concepts  were  first  discussed 
and  then  applied  to  a  real  software  product  which  was  featured 
throughout  this  thesis. 

Although  panacean  tools  and  techniques  for  the  software 
engineer  do  not  exist,  the  value  of  software  engineering 
principles  remains  great.  Until  an  adequate  number  of  software 
engineers  using  these  principles  has  been  developed,  the 
“software  crisis"  will  continue  to  be  the  major  restraint  on 
the  progress  of  computer  technology. 
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APPENDIX  A 


THE  SYSTEM  DATA  PLOW  DIAGRAMS 


Figure  A.l  The  System  Data  Flow  Diagram 


Figure  A. 2  Process  PI 
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APPENDIX  B 


THE  DATA  DICTIONARY 
Section  B.l.  The  Data  Stores 

D1  :  NEW  ENLISTED  SOLDIERS 

1.  ID_NUMBER 

2.  SOLDIER  NAME 

3.  DATE  ENLISTED 

4.  SERVICE  DURATION 

5.  CLASS 

6.  MARITAL  STATUS 

7.  NUMBER  OF  CHILDREN 

8.  FINANCIAL  STATUS 

9.  FAMILY  SUPPORTER 

10.  NUMBER  OF  BROTHERS  IN  SERVICE 

11.  SPECIALREASONS  FOR  TRANSFER 

12.  PREFERED  UNITS 

13.  ADDRESS 

14.  TOTAL  NUMBER  OF  ENLISTED 

D2  :  REQUIRED  NUMBER  OF  SOLDIERS  FOR  EACH  SPECIALTY 

1.  SPECIALTY 

2.  REQUIRED  SOLDIERS  FOR  SPECIALTY  TRAINING 

D3  :  SOLDIERS  WHO  COMPLETED  SPECIALTY  TRAINING 

1.  I D_NUMBER 

2.  SOLDIER  NAME 

3.  SPECIALTY 
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D4  :  SOLDIERS 

1.  I D_NUMBER 

2.  SOLDIER  NAME 

3.  DATE  ENLISTED 

4.  SERVICE  DURATION 

5.  CLASS 

6.  MARITAL  STATUS 

7.  NUMBER  OF  CHILDREN 

8.  FINANCIAL  STATUS 

9.  FAMILY  SUPPORTER 

10.  NUMBER  OF  BROTHERS  IN  SERVICE 

11.  SPECIAL  REASONS  FOR  TRANSFER 

12.  PREFERED  UNITS 

13.  ADDRESS 

14.  SPECIALTY 

15.  ASSIGNED  UNIT 

16.  DATE  ASSIGNED 

17.  COMPLETED  TRAINING 

18.  DATE  WHEN  REMAINING  SERVICE  EQUALS  4  MONTHS 

D5  :  UNITS 

1.  SPECIALTY 

2.  UNIT- NAME 

3.  REQUIRED  NUMBER  OF  SOLDIERS 

4.  EXISTING  NUMBER  OF  SOLDIERS 

5.  COMPLEMENT  NUMBER  OF  SOLDIERS 

D6  :  ASSIGNMENTS 

1.  I D_NUMBER 

2.  SOLDIER  NAME 

3.  SPECIALTY 
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4.  UNIT  ASSIGNED  TO 

5.  DATE  OF  REPORT 

D7  :  CHANGES  OF  STATUS 

1.  IDJMUMBER 

2.  CHANGED  NAME 

3.  CHANGED  SERVICE  DURATION 

4.  CHANGED  MARITAL  STATUS 

5.  CHANGED  NUMBER  OF  CHILDREN 

6.  CHANGED  FINANCIAL  STATUS 

7.  CHANGED  FAMILY  SUPPORTER 

8.  CHANGED  NUMBER  OF  BROTHERS  IN  SERVICE 

9.  CHANGED  SPECIAL  REASONS  FOR  TRANSFER 

10.  CHANGED  PREFERED  UNITS 

11.  CHANGED  ADDRESS 

D8  :  RETIRED  SOLDIERS 

1.  I D_NUMBER 

2.  SOLDIER  NAME 

3.  SPECIALTY 

4 .  UNIT 

5.  DATE  RETIRED 

D9  :  SPECIALTIES 

1.  SPECIALTY 

DIO:  HISTORY 

1.  I D_NUMBER 

2.  SOLDIER  NAME 

3.  DATE  ENLISTED 

4.  CLASS 

5.  ADDRESS 
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6.  SPECIALTY 

7.  DATE  RETIRED 

Dll  :  SOLDIER  QUALIFICATION  POINTS 

1.  I D_NUMBER 

2.  SPECIALTY 

3.  QUALIFICATION  POINTS 

D12  s  UNIT  NEEDS 

1.  SPECIALTY 

2.  UNIT  NAME 

3.  NEEDS 

D13  :  UNIT  NAMES 

1.  UNIT  NAME 

014  *  CURRENTLY  TRAINING  SOLDIERS 

1.  ID_NUMBER 

2.  SPECIALTY 

Sec t i on  B . 2 .  The  Data  Elements 

Name:  IDNUMBER 

A1 iases : 

Description:  A  number  given  to  a  soldier  during  enlistment, 
that  uniquely  identifies  him. 

Format:  Numeric,  PIC  9(7) 

Location:  D1 ,  D3,  D4,  D6 ,  D7 ,  D8,  DIO,  Dll,  D14 

Name:  SOLDIER  NAME 

Aliases:  CHANGED  NAME 

Description:  The  name  of  a  soldier  in  the  form: 

First,  Last,  Middle  Initial. 
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Format : 
Location : 

Name : 

A1 iases : 
Description : 
Format: 
Location : 

Name : 

A 1 iases : 
Description : 
Format : 
Location : 

Name : 

A1 iases : 
Description : 

Format : 

Location : 

Name : 

Aliases : 
Description : 

Format : 
Location : 

Name : 

A1 iases : 


Character,  PIC  X ( 36 ) 

Dl,  D3 ,  D4 ,  D6,  DB ,  DIO 

DATE  ENLISTED 

The  date  of  the  soldier  enlistment 
Date,  PIC  X ( B ) 

Dl,  D4 ,  DIO 

SERVICE  DURATION 
CHANGED  SERVICE  DURATION 

The  duration  of  the  soldier  service  time  in  months 
Numeric,  PIC  9(2) 

Dl  ,  D4 

CLASS 


All  soldiers  enlisted  in  the  same  period  belong  in 
the  same  Class 

A 1 phanumer ic ,  PIC  X(3)  (two  digits  followed  by  a 
letter.  eg.  87B ,  87E ,  88A ) 

Dl,  D4 ,  DIO 

MARITAL  STATUS 
CHANGED  MARITAL  STATUS 

The  marital  status  of  the  soldier,  (eg.  married, 
single,  divorced,  etc) 

Character  PIC  X(7) 

Dl,  D4 


NUMBER  OF  CHILDREN 
CHANGED  NUMBER  OF  CHILDREN 
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Description : 
Format : 
Location : 

Name : 

Aliases : 
Description : 
Format : 

Location : 

Name : 

A 1 iases : 
Description : 

Format : 
Location : 

Name : 

A 1 iases : 
Description : 

Format : 
Location : 

Name : 

A1 iases : 
Description : 

Format : 
Location : 


The  number  of  the  soldier's  children 
Numeric ,  PIC  9(1) 

D1  ,  D4 

FINANCIAL  STATUS 

CHANGED  FINANCIAL  STATUS 

The  soldier  financial  status 

Character,  PIC  X(l) 

(G  =  Good,  M  =  Medium,  B  =  Bad) 

D1  ,  D4 


FAMILY  SUPPORTER 
CHANGED  FAMILY  SUPPORTER 

A  soldier  is  considered  family  supporter  if  his 
father  has  died  and  he  is  the  oldest  son. 

Character,  PIC  X(3)  (YES,  NO) 

D 1  ,  D4 

NUMBER  OF  BROTHERS  IN  SERVICE 

CHANGED  NUMBER  OF  BROTHERS  IN  SERVICE 

The  number  of  a  soldier's  brothers  serving  the 
Armed  Forces . 

Numeric,  PIC  9(1) 

D  1  ,  D  4 

SPECIAL  REASONS  FOR  TRANSFER 

CHANGED  SPECIAL  REASONS  FOR  TRANSFER 

A  logical  field  that  becomes  true  if  the  soldier 
has  special  reasons  to  be  transfered  to  a  specific 
unit. 

Log ica 1 ,  T  or  F 
D 1  ,  D4 
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Name 


PREFERED  UNITS 


A1 iases : 
Description : 

Format: 
Location : 

Name : 

A 1 iases : 
Description : 
Format : 


Location : 

Name : 

A 1 iases : 
Description : 
Format : 
Location : 

Name : 

A I iases : 
Description : 
Format : 
Location : 

Name: 
Aliases: 
Description : 


CHANGED  PREFERED  UNITS 

The  names  of  three  units  the  soldier  prefers  to  be 
transferee!  to,  in  order  of  preference. 

Character,  PIC  X(21) 

Dl,  D4 


ADDRESS 

CHANGED  ADDRESS 

The  soldier  civilian  address 

Character,  PIC  X(69) 

Street,  PIC  X(15) 

City,  PIC  X ( 20 ) 

State,  PIC  X ( 1 5 ) 

ZIP,  PIC  X( 5) 

Phone ,  PIC  X  (  14  ) 

Dl,  D4 ,  DIO 


TOTAL  NUMBER  OF  ENLISTED 


The  total  number  of  new  enlisted  soldiers 
Numeric,  PIC  9(4) 

Dl 


SPECIALTY 


The  name  of  the  soldier's  specialty 
Character,  PIC  X(8) 

D2 ,  D3 ,  D4 ,  D5 ,  D6 ,  D8 ,  D9,  DIO,  Dll,  D12,  Dl 


REQUIRED  SOLDIERS  FOR  SPECIALTY  TRAINING 


The  number  of  new  enlisted  soldiers  who  must  be 
trained  in  each  specialty  to  cover  the  units  needs. 


0 


Format : 
Location : 

Name : 

Aliases : 
Description : 
Format : 
Location : 

Name : 

A 1 iases : 
Description : 
Forma t : 
Location : 

Name : 

A 1 iases : 
Description : 

Format : 
Location : 

Name : 

A 1 iases : 
Description : 

Format : 
Location : 

Name : 

A1 iases : 


Numeric,  PIC  9{4) 

D2 

ASSIGNED  UNIT 

UNIT,  UNIT  NAME,  UNIT  ASSIGNED  TO 

The  name  of  the  unit  a  soldier  is  assigned  to 

Character,  PIC  X(7) 

D4 


DATE  ASSIGNED 
DATE  OF  REPORT 

The  date  when  a  soldier  is  assigned  to  a  unit. 
Date,  PIC  X ( 8 ) 

D8 


COMPLETED  TRAINING 


A  logical  field  that 
completes  his  specia 


becomes  true  when  a  soldier 
ty  train ing  . 


Log ica 1  ,  T  or  F 


D4 


DATE  WHEN  REN.  SERVICE  =  4  MONTHS 


The  date  when  the  remaining  service  time  of  the 
soldier  becomes  equal  to  4  months.  This  date  is 
used  in  calculating  the  training  needs. 

DATE,  PIC  X ( 8 ) 

D4 


UNIT  NAME 

ASSIGNED  UNIT,  UNIT  ASSIGNED  TO,  UNIT 
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Description : 
Format : 
Location : 

Name: 

A1 iases: 
Description : 

Format : 
Location : 

Name : 

Aliases : 
Description : 

Format : 
Location : 

Name : 

A 1 iases : 
Description : 

Format : 
Location : 

Name : 

Aliases : 
Description : 
Format : 
Location : 


The  name  of  a  unit. 
Character,  PIC  X(7) 

D5 ,  D12,  D13 

REQUIRED  NUMBER  OF  SOLDIERS 


The  number  of  soldiers  of  a  specific  specialty 
required  to  meet  a  unit's  needs. 

Numeric,  PIC  9(3) 

D5 

EXISTING  NUMBER  OF  SOLDIERS 


The  number  of  soldiers  of  a  specific  specialty 
in  a  unit. 

Numeric ,  PIC  9(3) 

D5 


COMPLEMENT  NUMBER  OF  SOLDIERS 


The  difference  between  the  required  and  existing 
number  of  soldiers  in  a  unit. 

Numeric,  PIC  9(3) 

D5 

UNIT  ASSIGNED  TO 

UNIT,  ASSIGNED  UNIT,  UNIT  NAME 

The  unit  to  which  a  soldier  is  assigned. 

Character,  PIC  X(7) 

D6 
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Name : 


DATE  OP  REPORT 


Aliases:  DATE  ASSIGNED 

Description:  The  date  when  a  soldier  is  assigned  to  a  unit. 
Format:  Date,  PIC  X(8) 

Location:  D6 

Name:  CHANGED  NAME 

Aliases:  SOLDIER  NAME 

Description:  The  changed  name  of  a  soldier  in  the  form: 
Last,  First,  Middle  Initial. 

Format:  Character,  PIC  X ( 36 ) 

Location:  D7 

Name:  CHANGED  SERVICE  DURATION 

Aliases:  SERVICE  DURATION 

Description:  New  service  time  for  a  soldier  in  months. 
Format:  Numeric,  PIC  9(2) 

Location:  D7 

Name:  CHANGED  MARITAL  STATUS 

Aliases:  MARITAL  STATUS 

Description:  The  new  marital  status  of  a  soldier. 

Format:  Character,  PIC  X(7) 

Location:  D7 

Name:  CHANGED  NUMBER  OF  CHILDREN 

Aliases:  NUMBER  OF  CHILDREN 

Description:  The  new  number  of  children  of  a  soldier. 
Format:  Nummeric ,  PIC  9(1) 

Location:  D7 
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Name : 

Aliases : 
Description : 
Format : 
Location : 

Name : 

Aliases : 
Description : 

Format : 
Location : 

Name : 

A 1 iases : 
Description : 

Format : 
Location : 

Name : 

A1 iases : 
Description : 

Forma t : 
Location : 

Name : 

Aliases : 
Description : 

Format : 


CHANGED  FINANCIAL  STATUS 
FINANCIAL  STATUS 

The  new  financial  status  of  a  soldier. 
Character,  PIC  X ( 1  ) 

D7 


CHANGED  FAMILY  SUPPORTER 
FAMILY  SUPPORTER 

The  new  status  of  the  soldier  relatively  to 
being  a  family  supporter  or  not. 

Character,  PIC  X  <  3 ) 

D7 


CHANGED  NUMBER  OF  BROTHERS  IN  SERVICE 

NUMBER  OF  BROTHERS  IN  SERVICE 

The  new  number  of  the  soldier's  brothers 
serving  the  Armed  Forces. 

Numeric ,  PIC  9(1) 

D7 


CHANGED  SPECIAL  REASONS  FOR  TRANSFER 
SPECIAL  REASONS  FOR  TRANSFER 

This  field  is  updated  whenever  the  special 
reasons  for  transfer  change. 

Logical ,  T  or  F 

D7 


CHANGED  PREFERED  UNITS 
PREFERED  UNITS 

The  names  of  three  units  the  soldier  wants  to  be 
transfered  to,  in  order  of  preference. 

Character,  PIC  X(21) 
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Location : 


D7 


Name : 

A1 iases : 
Description : 
Format : 
Location : 

Name : 

A1 iases: 
Description : 

Format : 
Location : 

Name : 

Aliases : 
Description : 
Format : 
Location : 

Name : 

A1 iases : 
Description : 
Format : 
Location : 

Name : 

Aliases : 
Description : 

Format : 
Location : 


CHANGED  ADDRESS 
ADDRESS 

The  new  address  of  a  soldier, 
see  ADDRESS 
D7 

QUALIFICATION  POINTS 


A  number  calculated  during  the  assignments  process. 
The  higher  this  number,  the  more  probable  for  a 
soldier  to  be  transfered  to  the  unit  he  prefers. 

Numeric,  PIC  9(3) 

Dll 


UNIT 

ASSIGNED  UNIT,  UNIT  NAME,  UNIT  ASSIGNED  TO 
The  unit  name  of  a  retired  soldier. 
Character,  PIC  X(7) 

D8 

DATE  RETIRED 


The  date  when  the  soldier  retired  from  service. 
Date,  PIC  X ( 8 ) 

D8 ,  DIO 

NEEDS 


The  number  of  soldiers  of  a  specialty  that  a  unit 
requires  to  acompl ish  its  mission. 

Numeric,  PIC  9(3) 

D12 
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APPENDIX  C 


PROCESS  DESCRIPTIONS 


Section  C.l  :  Algorithm  Description  of  Process  PI 

INPUT  :  Dl,  D4,  D5,  D9,  D14 
OUTPUT  :  D2 
PROCESS  : 

Get  TOTAL_ENL  (total  number  of  new  enlisted  soldiers) 
f ram  Dl . 

Get  CURRENT  DATE. 

Calculate  TOTAL_REQ  (total  number  of  required  soldiers  for 
all  spesialties)  as  follows: 

TOT  AL_REQ  =  T(JTAL_COMPL  +  TOT  AL_RET  +  TOT  AL_TR  where: 
TOT AL_COMPL  =  The  sum  of  all  COMPLEMENT  fields  in  D5 
TOTAL_RET  =  The  number  of  records  in  D4  with  DATE 
WHEN  REMAINING  SERVICE  EQUALS  4  MONTHS 
earlier  than  CURRENT  DATE. 

TQTAL_TR  =  The  number  of  records  in  D14. 

For  each  Specialty  i  in  D9  do  the  following: 

Calculate  COMi  (the  number  of  soldiers  needed  to  sa¬ 
tisfy  the  needs  of  all  units  for  this  specialty  )  by 
adding  all  COMPLEMENT  fields  for  Specialty  i  in  D5. 
Calculate  TRi  (number  of  soldiers  currently  training 
in  Specialty  i)  by  counting  the  records  in  D14  with 
SPECIALTY  =  i) 
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Calculate  RETi  (number  of  soldiers  to  retire  within 
the  next  4  months)  by  counting  the  records  in  D4 
with  DATE  WHEN  REMAINING  SERVICE  EQUALS  4  MONTHS 
earlier  than  CURRENT  DATE  and  SPECIALTY  =i . 

Calculate  REQi  (total  number  of  soldiers  required  to 
fully  satisfy  the  needs  for  Specialty  1)  as  follows: 
REQi  =  COMi  +  RETi  -  TRi 

Calculate  Xi  (number  of  new  enlisted  soldiers  to  be 
trained  in  Specialty  i)  as  follows: 

Xi  =  REQi  *  TOTAL_ENL  /  TOT  AL_REQ 

Append  a  record  to  data  store  D2 . 

Store  i  and  Xi  in  D2 . 


Section  C.2 


jorithm  Description  of  Process  P2 . 1 


INPUT  :  D1 
OUTPUT  :  D4 
PROCESS  : 

For  each  record  in  D1  do  the  following: 

Create  a  new  record  in  D4 . 

Road  all  the  fields  from  the  record  in  D1  into  the 
respective  fields  of  the  record  in  D4 . 

Initialize  the  rest  of  the  fields  of  the  record  in  D4 : 
COMPLETED  TRAINING  =  False 
SPECIALTY  =  "11  .  .  .  Z" 

ASSIGNED  UNIT  =  "11...1" 

DATE  ASSIGNED  =-  01/01/01 

DATE  WHEN  REMAINING  SERVICE  EQUALS  4  MONTHS  = 

(DATE  ENLISTED)  +  (DURATION  OF  SERVICE)  -  (4  Months) 
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Section  C.3 


Algorithm  Description  of  Process  P2.2.1 


INPUT 

OUTPUT 

PROCESS 

For 


Section 

INPUT 

OUTPUT 

PROCESS 

For 


Section 

INPUT 

OUTPUT 

PROCESS 

For 


:  D3 
:  D4 

each  record  in  D3  do  the  following: 

Read  the  ID_NUMBER  and  SPECIALTY. 

Find  the  record  of  the  soldier  in  D4  using  ID_NUMBER 
as  a  key. 

Update  the  SPECIALTY  field. 

Write  "True"  into  the  COMPLETED  TRAINING  field. 

C . 4  :  Algorithm  Description  of  Process  P2 . 2 . 2 


:  D6 
:  D4 


each  record  in  uo  do  the  following: 

Read  the  I  D__NUMBER ,  UNIT  A5SIGNED  TO  and  DATE  OF 
REPORT . 

Fi^r)  the  record  in  D4  with  the  same  ID_NUMBER. 

Update  the  ASSIGNED  UNIT  and  ASSIGNED  fields  in  this 
record . 

C . 5  :  Algorithm  Description  of  Process  P2.2.3 

:  D7 
:  D4 

each  record  in  D7  do  the  following: 

Read  the  ID_NUMBER  and  the  rest  fields. 

Find  the  record  in  04  with  the  same  ID  ‘‘"UMBER. 
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If  CHANGED  SERVICE  DURATION  <>  99  then 

(DATE  WHEN  REMAINING  SERVICE  EQUALS  4  MONTHS)  = 
(DATE  ENLISTED)  +  (CHANGED  DURATION  OF  SERVICE)  - 
( 4  MONTHS ) . 

If  CHANGED  NAME  <>  then 

update  SOLDIER  NAME  in  D4 . 

If  CHANGED  MARITAL  STATUS  <>  "ZZ...Z"  then 
update  MARITAL  STATUS  in  D4 . 

If  CHANGED  FINANCIAL  STATUS  <>  "ZZ...Z"  then 
update  FINANCIAL  STATUS  in  D4 . 

If  CHANGED  FAMILY  SUPPORTER  <>  False  then 
update  FAMILY  SUPPORTER  in  D4 . 

If  CHANGED  NUMBER  OF  CHILDREN  <>  9  then 
update  NUMBER  OF  CHILDREN  in  D4 . 

If  CHANGED  SPECIAL  REASONS  FOR  TANSFER  <>  False  then 
update  SPECIAL  REASONS  FDR  TRANSFER  in  D4 . 

If  CHANGED  PREFERED  UNIT  1  <>  "ZZ...Z"  then 
update  PREFERED  UNIT  1  in  D4 . 

If  CHANGED  PREFERED  UNIT  2  <>  "21... 1"  then 
update  PREFERED  UNIT  2  in  D4 . 

If  CHANGED  PREFERED  UNIT  3  <>  "11... 1"  then 
update  PREFERED  UNIT  3  in  D4 . 

If  CHANGED  STREET  <>  "11... 1"  then 
update  STREET  in  D4 . 

If  CHANGED  CITY  <>  " Z Z . . . Z ”  then 
update  CITY  in  D4 . 

If  CHANGED  STATE  <>  "11... 1"  then 
update  STATE  in  D4 . 

If  CHANGED  ZIP  <>  "11...1"  then 
update  ZIP  in  D4 . 
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Section 

INPUT 

OUTPUT 

PROCESS 

For 


Sec  t ion 

INPUT 

OUTPUT 

PROCESS 

For 


If  CHANGED  PHONE  <>  "ZZ...Z"  then 
update  PHONE  in  D4 . 

C .6  :  Algorithm  Description  of  Process  P2.3 

:  D4 ,  D8 
:  D4 ,  DIO 

each  record  in  DB  do  the  following: 

Read  the  ID_NUMBER  and  the  DATE  RETIRED. 

Find  the  record  in  D4  with  the  same  ID_NUMBER. 

Create  a  new  record  in  DIO. 

Transfer  the  following  fields  into  the  respective 
fields  in  DIO: 

-  I D_NUMBER 

-  SOLDIER  NAME 

-  DATE  ENLISTED 

-  CLASS 

-  ADDRESS 

-  SPECIALTY 

Write  DATE  RETIRED  into  the  respective  field  in  DIO. 
Delete  the  record  from  D4 . 

C .  7  :  Algorithm  Description  of  Process  P3.1 


:  D8 
:  D5 

each  record  in  D8  do  the  following: 
Read  the  UNIT  and  SPECIALTY 


Find  the  unit  record  in  D5 


using  UNIT  and  SPECIALTY 


Sec  tion 

INPUT 

OUTPUT 

PROCESS 

For 


Section 

INPUT 

OUTPUT 

PROCESS 

For 


Decrement  by  1  the  EXISTING  field. 
Increment  by  1  the  COMPLEMENT  field. 


C . 8  :  Algorithm  Description  of  Process  P3.2 


.  D6 

:  D5 

each  record  in  D6  do  the  following: 

Read  the  UNIT  ASSIGNED  TO  and  SPECIALTY. 

Find  the  record  in  D5,  using  UNIT  ASSIGNED  TO 
SPECIALTY  as  a  key. 

Increment  by  1  the  EXISTING  field. 

Decrement  by  1  the  COMPLEMENT  field. 

C . 9  :  Algorithm  Description  of  Process  P4 . 1 

:  D3 ,  D4 

:  Dll 

each  record  in  D3  do  the  following: 

Initialize  variable  POINTS  =  0 

Read  the  I D_NUMER  and  SPECIALTY. 

Find  the  record  in  D4  with  the  same  ID_NUMBER. 

If  MARITAL  STATUS  =  "MARRIED"  then 
add  40  to  POINTS. 

If  NUMBER  OF  CHILDREN  >  ±  then 
add  70  to  POINTS. 

If  NUMBER  OF  CHILDREN  =  1  then 
add  35  to  POINTS. 

If  FAMILY  SUPPORTER  =  True  then 
add  40  to  POINTS. 


and 
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Section 

INPUT 

OUTPUT 

PROCESS 

For 


For 


If  FINANCIAL  ABILITY  =  ••BAD"  then 
add  20  to  POINTS. 

If  FINANCIAL  ABILITY  =  "MEDIUM"  then 
add  10  to  PP I  NTS . 

If  NUMBER  OF  BROTHERS  IN  SERVICE  >  1  then 
add  20  to  POINTS. 

If  NUMBER  OF  BROTHERS  IN  SERVICE  =  1  then 
add  10  to  POINTS. 

If  SPECIAL  REASONS  FOR  TRANSFER  =  True  then 
add  10  to  POINTS. 

Add  a  new  record  to  Dll. 

Write  the  I D_NUMER ,  POINTS  and  SPECIALTY  into  the 
respective  fields  in  Dll. 


C.IO  :  Algorithm  Description  of  Process  P4 . 2 

:  D3 ,  D5 ,  D9 ,  D13 

:  D12 

• 

• 

each  record  in  D9  do  the  following: 

Read  the  SPECIALTY  name. 

Calculate  T0TAL_A5SIGN  (number  of  soldiers  to  be  as¬ 
signed  for  this  specialty),  by  counting  the  records 
in  D3  with  the  same  SPECIALTY  name. 

Calculate  T0TAL_REQ  (number  of  soldiers  of  this  spe¬ 
cialty  required  for  all  units),  by  summing  up  the 
COMPLEMENT  fields  for  this  specialty  in  D5. 

each  record  in  D13  do  the  following: 

Read  the  UNIT  NAME. 

Find  the  record  in  D5,  using  SPECIALTY  and  UNIT  NAME 
as  a  key. 
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Read  the  COMPLEMENT  field  in  this  record. 

Ca leu  late: 

NEEDS  =  <TOTAL_ASSIGN  /  TOTAL_REQ)  *  COMPLEMENT 
Create  a  record  in  D12. 

Write  the  UNIT  NAME,  SPECIALTY  and  NEEDS  into  the 
respective  fields. 


Section  C.ll  :  Algorithm  Description  of  Process  P4 . 3 

INPUT  :  D3 ,  D4 ,  Dll,  D12 
OUTPUT  :  D6 
PROCESS  : 

Get  CURRENT  DATE. 

DATE  OF  REPORT  =  CURRENT  DATE  +  7  DAYS. 

Sort  Dll  by  SPECIALTY  and  QUALIFICATION  POINTS. 

For  each  record  in  Dll  do  the  following: 

Read  the  I D_NUMBER  and  SPECIALTY. 

Find  the  record  in  D4  with  the  same  ID_NUMBER. 

Read  the  PREFERED  UNIT  1,  PREFERED  UNIT  2  and  PREFERED 
UNIT  3. 

Find  the  record  in  D12  using  PREFERED  UNIT  1  and 
SPECIALTY  as  a  key. 

If  NEEDS  >  0  then 

assign  the  soldier  to  prefered  unit  1  as  follows: 

-  Subtract  1  from  the  NEEDS  field  in  D12. 

-  Write  the  I D_NUMBER ,  SPECIALTY  and  PREFERED  UNIT  1 
in  a  new  record  in  D6. 

Else  find  the  record  in  D12  using  PREFERED  UNIT  2  and 
SPECIALTY  as  a  key. 
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If  NEEDS  >  0  then 


assign  the  soldier  to  prefered  unit  2  as  above. 
Else  find  the  record  in  D12  using  PREFERED  UNIT  3 
and  SPECIALTY  as  a  key. 

If  NEEDS  >  0  then 

assign  the  soldier  to  prefered  unit  3  as  above. 
Else  assign  the  soldier  to  the  first  unit  in  D12 
in  which  the  NEEDS  for  this  SPECIALTY  is  >  0. 


Section  C.12  :  Algorithm  Description  of  Process  P5.1 


INPUT  :  Manual  list  of  Retired  soldiers 
OUTPUT  :  D8 
PROCESS  : 

Delete  all  previous  records  from  DB. 

For  each  record  in  the  manual  list  do  the  following: 

Append  a  record  to  DB. 

Read  the  ID_NUMBER,  SOLDIER  NAME,  SPECIALTY,  UNIT  and 
DATE  RETIRED  fields  into  the  respective  fields  in  DB 


Section  C.13 


lorithm  Description  of  Process  P5.2 


INPUT  :  Manual  list  of  Soldiers  who  completed  spec,  training 
OUTPUT  :  D3 
PROCESS  : 

Delete  all  previous  records  from  D3. 

For  each  record  in  the  manual  list  do  the  following: 

Append  a  record  to  D3. 

Read  the  I D JNUMBER ,  SOLDIER  NAME  and  SPECIALTY  fields 
into  the  respective  fields  in  D3. 
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INPUT 


on  C.14  :  Algorithm  Description  of  Process  P5.3 

:  Manual  list  of  changes  in  soldier  status 
OUTPUT  s  D7 
PROCESS  : 

Delete  all  previous  records  from  D7 . 

For  each  record  in  the  manual  list  do  the  followings 
Append  a  record  to  D7. 

Read  all  fields  of  the  manual  list  record  into  the 

respective  fields  of  the  record  in  D7 . 

Section  C.15  *  Algorithm  Description  of  Process  P5.4 

INPUT  :  Manual  list  of  new  enlisted  soldiers 

OUTPUT  s  D1 

PROCESS  : 

Delete  all  previous  records  from  Dl. 

For  each  record  in  the  manual  list  do  the  followings 
Append  a  record  to  Dl. 

Read  all  fields  in  the  manual  list  record  into  the 

respective  fields  of  the  record  in  Dl . 

Section  C.16  s  Algorithm  Description  of  Process  P5.5 

I NPUT  s  Manual  list  of  soldiers  enrolled  in  special  training 
OUTPUT  s  D 1 4 
PROCESS  s 

Delete  all  previous  records  from  D14. 

For  each  record  in  the  manual  list  do  the  followings 
Append  a  record  to  D14. 

Read  the  ID_NUMBER  and  SPECIALTY  fields  from  the  list 
into  the  respective  fields  of  the  record  in  D14. 
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Section  C.17  :  Aloorithm  Description  of  Process  P6.1 


INPUT  :  D2 

OUTPUT  :  Printed  list  of  TRAINING  NEEDS 

PROCESS  : 

Prepare  the  system  printer  to  print. 

Print  the  list  according  to  a  desired  format. 

Section  C.1S  :  Algorithm  Description  of  Process  P6.2 
INPUT  :  D6 

OUTPUT  :  Printed  list  of  ASSIGNMENTS 

PROCESS  : 

Prepare  the  system  printer  to  print. 

Print  the  list  according  to  a  desired  format. 
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1  REPORTS 


1200 

JSSIGHT _ 

:  PROCESS 
ASSIGRBERTS 


EIL_SLDS _ 

;  PROCESS  nei 
IILISTED 

SOLDIERS 
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Process 
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REPORTS 
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Figure  D.l  The  System  Structure  Chart 
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PROGRAM  LEVEL 

DESCRIPTION 

0 

B 

2 

3 

1000 

1100 

Main  control  program  of  the  PERSONNEL  MANA¬ 
GEMENT  SYSTEM.  It  displays  a  menu  screen  and 
depending  on  the  user's  choice  it  gives  con¬ 
trol  to  one  of  five  functions. 

-  Enters  the  units  reports  into  the  system 
and  performs  the  necessary  updates  to  the 
system  files. 

1110 

-  Enters  the  units  report  for  RETIRED  SOL¬ 
DIERS  to  the  system  and  updates  the  UNIT 
ORG,  HISTORY,  SLD_ADDR  and  SLD_SERV  file. 

1111 

-  Creates  the  RETIRED  file  and  updates 
it  with  the  data  from  the  unit  report. 

1112 

-  Reads  each  record  in  the  RETIRED  file 
and  updates  the  UNIT_0RG  file. 

1113 

-  Reads  each  record  in  the  RETIRED  file, 
updates  the  HISTORY  file  and  deletes 
the  soldier  record  from  the  SLD  ADDR 
and  SLD_SERV  files. 

1120 

-  Enters  the  units  reports  for  CHANGES  in 
SOLDIER  DATA  to  the  system  and  updates 
the  SLD_ADDR ,  SLD.SERV,  SLD_TRANSF  and 
SLD_PREF  files. 

1121 

1122 

-  Creates  the  CHANGES  file  and  updates 
it  with  the  data  from  the  unit  report. 

-  Reads  each  record  in  the  CHANGES  file 
and  updates  the  SLD  ADDR,  SLD  SERV, 
SLD_TRANSF  and  SLD_PREF  files. 

1200 

-  Calls  other  modules  which  assign  soldiers 
to  units,  update  the  units  and  soldier 
files  and  print  the  list  of  assignments. 

1210 

-  Calculates  transfer  qualification  points 
for  each  soldier  and  updates  the  TRSF_PTS 
file. 

1220 

-  Calculates  the  units  needs  for  soldiers 
of  each  specialty  and  updates  the 

UNIT_REQ  file. 

1230 

-  Considers  the  soldier  transfer  points, 
his  preferences  and  the  unit,  needs  and 
assigns  each  soldier  to  a  unit.  This  de¬ 
cision  is  entered  into  the  ASSIGNMS  file. 

Figure  D.2  The  Visual  Table  of  Contents  (VTOC) 

of  the  Personnel  Management  System  (Contin.) 
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PROGRAM  LEVEL 

DESCRIPTION 

0 

H 

2 

3 

1240 

-  Reads  each  record  in  the  ASSIGNMS  file 
and  updates  the  UNIT_0RG  file. 

1250 

-  Reads  each  record  in  the  ASSIGNMS  file 
and  updates  the  SLD_SERV  file. 

1260 

-  Prints  the  list  of  ASSIGNMENTS. 

1300 

-  Enters  the  EC  report  for  new  ENLISTED 
SOLDIERS  into  the  system  and  updates  the 
ENLISTED,  SLD_ADDR ,  SLD_SERV,  SLD_TRANSF 
and  SLD_PREF  file6. 

1 3 1C 

-  Creates  the  ENLISTED  file  and  updates 
it  with  the  data  from  the  EC  report. 

1320 

-  Reads  each  record  in  the  ENLISTED  file 
and  updates  the  SLD_ADDR,  SLD  SERV, 
SLD_TRANSF  and  SLD_PREF  files. 

1400 

-  Calculates  the  training  needs  for  each 
specialty  and  prints  a  list  of  the  needs. 

1410 

-  Calculates  the  training  needs  for  each 
specialty  andstores  them  in  the 

TRAIN_REQ  file. 

1420 

-  Prints  the  list  with  the  training  needs 
for  each  specialty. 

1500 

-  Enters  the  STC  reports  into  the  system  and 
updates  the  necessary  files. 

1510 

-  Enters  the  STC  report  for  SOLDIERS  WHO 
COMPLETED  SPECIALTY  TRAINING  into  the 
system  and  updates  the  COMPL  TR  and 
SLD_SERV  files. 

1511 

-  Creates  the  C0MPL_TR  file  and  updates 
it  with  the  data  from  the  STC  report. 

1512 

-  Reads  each  record  in  the  COMPL_TR  file 
and  updates  the  SLD_SERV  file. 

1520 

-  Creates  the  TRAINEES  file  and  updates  it 
with  the  data  from  the  STC  report  for 
the  soldiers  currently  enrolled  in 
special  training. 

(contin.)  Figure  D.2  The  Visual  Table  of  Contents  (VTOC) 

of  the  Personnel  Management  System 
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SYSTEM  :  PERSONNEL  MANAGEMENT 

MODULE  NAME  :  PERS_MGT 

MODULE  No  :  1000 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


Figure  D.3.1  The  IPO  chart  of  program  PERS_MGT 
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1000 


Figure  D.3.1.a  The  flowchart  of  program  PERS-MGT 


2 
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Figure  D.3.2.a  The  flowchart  of  program  UNIT-REP 
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SYSTEM  :  PERSONNEL  MANAGEMENT 

MODULE  NAME  :  RET_REP 

MODULE  No  :  1110 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


Figure  D.3.3  The  IPG  chart  of  program  RET_REP 
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1110 


Figure  D.3.3.a  The  flowchart  of  program  RET-REP 
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SYSTEM  :  PERSONNEL  MANAGEMENT 

MODULE  NAME  :  GET_RET 

MODULE  No  :  1111 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


Figure  D.3.4  The  IPO  chart  of  program  GET_RET 
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1111 


Figure  D.3.4.a  The  flowchart  of  program  GET-RET 


SYSTEM  :  PERSONNEL  MANAGEMENT 

MODULE  NAME  :  UPUNRET 

MODULE  No  :  1112 

DESIGNER  :  Labros  Karatasioe  DATE  :  4/30/1987 


Figure  D.3.5  The  IPO  chart  of  program  UPUNRET 
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1112 


(pponret) 


OPEN  files: 
RETIRED ,  UNIT-ORG, 
SLD.SERV 


GET  next  record 
in  RETIRED 


M_ID_NUMBER  = 
RETIRED. ID.NUMBER 


Look  up 
M_ID_NUMBER 
in  SLD_SERV 


M.SPECI ALTY=SLD_SERV . SPECIALTY 
M  UNIT^SLD  SERV .UNIT 


Look  up 
M_SPECIALTY  and  M.UNIT 
in  U NIT_ORG 


DISPLAY; 
ERROR 
'MESSAGE 


UNIT_ORG. EXISTING  = 
UNIT_ORG. EXISTING  -  1 


CLOSE 

FILES 


UNIT_ORG. COMPLEMENT  = 
UNIT.ORG. COMPLEMENT  +  1 


C  ewe  ) 


Figure  D3.5.a  The  flowchart  of  program  UPUNRET 
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SYSTEM 
MODULE  NAME 
MODULE  No 
DESIGNER 


PERSONNEL  MANAGEMENT 

UPD_HIST 

1113 

Labros  Karatasios  DATE  :  4/30/1987 


INVOKED  BY  MODULE  : 

INVOKES  MODULES  : 

1110 

INPUTS  : 

OUTPUTS  : 

RETIRED.  SLD  ADDR , 

HISTORY.  SLD  ADDR. 

SLD  SEFV 

SLD  SERV.  SLD  TRAN. 

SLD_PREF 

PROCESS  :  See  Flowchar 

t  in 

F igure  D . 3 . 6 . a 
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1113 


(ppd-hist) 

1 


OPEN  files: 

RETIRED,  SLD_ADDR ,  SLD_SERV 
SLD_TRANSF ,  SLD_PREF ,  HISTORY 


GET  next  record 
in  RETIRED 


DELETE 

Irecord  from 
SLD_ADDR 


Look  ui 
M_ID_NUMBEF 
in  SLD_SERV 


(  END 


APPEND  a 
record  to 
HISTORY 

DELETE  record 
from  SLD_TRANSF 

I 

T 


HISTORY 

HISTORY 

HISTORY 

HISTORY 

HISTORY 

HISTORY 

HISTORY 

HISTORY 

HISTORY 


ID_NUMBER: 

F_NAME 

M_INITIAL= 

L_NAME 

STREET 

CITY 

STATE 

ZIP 

PHONE 


M_ID_NUMBER 
SLD_ADDR . F_NAME 
SLD_ADDR . M_INITIAL 
SLD_ADDR . L_NAME 
SLD_ADDR. STREET 
SLD+ADDR .CITY 
SLD_ADDR. STATE 
SLD_ADDR.ZIP 
SLD_ADDR. PHONE 


Look  up 
M_ID_NUMBER 
in  SLD_PREF 


& 


DELETE  record 
from  SLD_PREF 


Figure  D.3.6a  The  flowchart  of  program  UFD-HIST 
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Figure  D.3.7  The  IPO  chart  of  program  CHNG_REP 
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1120 


Figure  D.3.7.a  The  flowchart  of  program  CHNG-REP 
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Figure  D.3.8  The  IPO  chart  of  program  GET_CHNG 
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Figure  D.3.8a  The  flowchart  of  program  GET-CHNG 
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SYSTEM  :  PERSONNEL  MANAGEMENT 

MODULE  NAME  :  UPSLDCHN 

MODULE  No  :  1122 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


INVOKES  MODULES  : 


INPUTS  : 

OUTPUTS  : 

CHANGES 

SLD_ADDR ,  SLD  SEPV , 

r-  t  Tr:i;  C  r  t  •  t* r>  L’  L* 

*_>  i_i  .  _ x  -  \  n  *  i  ,  j-  _  i  £L  r 

PROCESS  :  See  Flowchart  in  Figure  D.3.9.a 


INVOKED  BY  MODULE  : 

1120 


Figure  D.3.9  The  IPO  chart  of  program  UPSLDCHN 
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1122 


Figure  D.3.9a  The  flowchart  of  program  UPSLDCHN  (part  1  of  2) 
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SLD_SERV . SERV_DUR= 
CHANGES . SERV_DUR 
SLD_SERV . DATE_4  = 
SLD_SERV . DATE_ENL 
+  CHANGES. SERV_DUR 
-  4  months 


SLD_TRANSF 
FAMSUPP  = 
CHANGES. 
FAN  SUPP 


Look  up 
M_I D_NUMBER 
in  SLD  PREF 


SLD_PREF . 
PREF  _UN I T 1  = 
CHANGES. 
PREF  UNIT! 


SLD  PREF. 
PREF  JJNI T2= 
CHANGES . 
PREF  UNIT2 


SLD_PREF . 
PREF _UN  I  T  3: 
CHANGE  S . 
PREF  UNIT3 


SYSTEM  :  PERSONNEL  MANAGEMENT 

MODULE  NAME  :  ASSIGNMT 

MODULE  No  :  1200 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


Figure  D.3.10  The  IPO  chart  of  program  ASSIGNMT 
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1200 


Figure  D.3.10a  The  flowchart  of  program  ASSIGNMT 
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SYSTEM  :  PERSONNEL  MANAGEMENT 

MODULE  NAME  :  CALC_PTS 

MODULE  No  :  1210 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


INVOKED  BY  MODULE  : 

INVOKES  MODULES  : 

1200 

INPUTS  : 

OUTPUTS  : 

COMPL_TF ,  SLD_TRAN 

TRSF.PTS 

PROCESS  :  See  Flowchart  in  Figure  D.3.11.a 


Figure  D.3.11  The  IPO  chart  of  program  CALC_PTS 
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1210 


fCALC-PTs) 

_ 

OPEN  files: 

COMPL  TR, 
SLD  TRANSF, 
TRSF  PTS 

_ 

1 

SLD  TRANSF 


N 


N 


GET  next  record 
in  COMPL_TR 

- 1 - 


VNUM  CHILDS 

PO I NTS= 
POINTS  +  70 

SLD_TRANSF 
NUM  CHILD, 


POI NTS= 
POINTS  +  35 


V  /'''EOF 

.COMPL  TR' 


_ 1 

PO I NTS= 

PO I NTS= 

POINTS  =  0 

POINTS  +  20 

POINTS  +  40 

M_I D_NUMBER= 
COMPL_TR. 

ID  NUMBER 


M_SPEC I ALTV= 
COMPL  TR. SPECIALTY 


Look  up 

M  ID  NUMBER 

in  SLD 

_TRANSF 

r 

PO I NTS= 

L 

PO I NTS= 

POINTS  +  10 

POINTS  +  20 

DISPLAY/ 
ERROR 
MESSAGE 


EOF 

sld  transf; 


N 


SLD  TRANSF . 


PO I NTS= 

u 

PO I NTS= 

POINTS  +  10 

POINTS  +  10 

CLOSE 

FILES 

"M"  ./tf 

APPEND  a 
record  to 

— 

TY 

TRSF_PTS 

POINTS  = 


—  V  I  UilX  I  u  —  J I 

END  )  POINTS  40| — 


TRSF_PTS . I D_NUMBER= 
M_ID_NUMBER 
TRSF_PTS . SPEC  I ALT Y  = 
M_SPEC I  ALT Y 
TRSF_PTS . QUAL_PTS= 
POINTS 


Figure  D.3.11a  The  flowchart  of  program  CALC-PTS 


A 
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Figure  D.3.12  The  IPO  chart  of  program  CLC_NEED 
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1220 


(CLC-NEED  ) 

_zi r 


OPEN  files: 
SPECS,  UNITS, 
COMPL_TR, 
UNITJDRG  , 
UNIT  REO 


INITIALIZE  vars 
I  TOTAL_ASS I GN  =  0 
TOT  AL_REQ  =  0 
COMPLEM  =  0 
UNIT  NEED  =  0 


GET  next  record 
in  UNIT  QRG 


Look  up 
MJJNIT  and  M_5PEC I ALTY 
in  UNIT  ORG 


COMPLEM= 

UNIT  ORG. COMPLEMENT 


UN I T_NEED  = 

TOTAL-ASSIGN  x  COMPLEM 
TOTAL  REQ 


APPEND  a  record 
to  UNIT  REO 


(  END  ) 


UN I T_REQ . SPEC  I ALTY  =  M_SPEC I ALTY 
UN I T_REQ . UN I T  =M_UNIT 

UNIT  REQ. NEEDS  =UNIT  NEED 


Figure  D.3.12a  The  flowchart  of  program  CLC-NEED 
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Figure  D.3.13  The  IPO  chart  of  program  ASGN_SLD 
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1230 

( asgn-sld) 


OPEN  files 
TRSF_PTS,  SLD_PRF,i 
UN  I  T_REQ  ,  ASSIGNMS| 

I 


GET  CURRENT  DATE 

, 

REPORT 

DATE  = 

CURRENT _D ATE  +7  DAYS 

_ i 

r 

Look  up  MJJNIT2 
and  M_SPEC I  ALT Y 
UNIT  REQ 


in 


SORT  TRSF_PTS 
by  QUAL  PTS 

♦  -  - 

Get  next  record 
in  TRSF  PTS 


Look  up  M_UNIT3 
and  M_SPECIALTY 
in  UNIT  REQ 


M_I  D  NUMBER  = 
TRSF_PTS . I D_NUMBER 
M_SPEC I ALTV  = 

TRSF  PTS. SPECIALTY 


Look  up  M_I D_NUMBER 
in  SLD  PREF 


10F 

:sld  pref; 


Look  up 
M_SPEC I ALT Y 
and  NEEDS>0 
jin  UNIT  REQ 


M  UN  I  T  1  = 

SLD  PREF.PRF 

UN  I  T  1 

M  UN I T2= 

SLD  PREF.PRF 

UNIT2 

M  UN  I T3  = 

SLD  PREF.PRF 

_UN I T3 

N 


DISPLAY/ 
'ERROR 
'MESSAGE/ 


Look  up  MJJNITl 
and  M_SPEC I  ALT Y — »/a) 
in  UNIT  REQ  w 


CLOSE 

FILES 


(  END  ) 


UNIT 

UNIT 


REQ, 

REQ, 


NEEDS  = 
NEEDS  - 


Append  a  record 
ASSIGNMS 


to 


ASSIGNMS. I D_NUMBER  = 
M_ID_NUMBER 
ASSIGNMS. UN  IT  = 

UN I T_REQ . UN  I T 

ASS  I GNMS . DATE_AS I GN  = 

REPORT_DATE 

ASSIGNMS. SPECIALTY  = 

M  SPECIALTY 


I 


Figure  D.3.13a  The  flowchart  of  program  ASGN-SLD 
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SYSTEM  :  PERSONNEL  MANAGEMENT 

MODULE  NAME  :  UPDUNASN 

MODULE  No  :  1240 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


INVOKED  BY  MODULE  : 

INVOKES  MODULES  : 

1200 

INPUTS  : 

OUTPUTS  : 

ASSIGNMS 

UNITJ3RG 

PROCESS  :  See  Flowchart  in  Figure  D.3.14.a 


Figure  D.3.14  The  IPO  chart  of  program  UPDUNASN 
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1240 


Figure  D.3.14.a  The  flowchart  of  program  UPDUNASN 
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SYSTEM  :  PERSONNEL  MANAGEMENT 

MODULE  NAME  :  UPSLDASN 

MODULE  No  :  1250 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


Figure  D.3.15  The  IPO  chart  of  program  UPSLDASN 


140 


1250 
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SYSTEM 

:  PERSONNEL  MANAGEMENT 

MODUf.E  NAME 

:  PR_ASIGN 

MODULE  No 

:  1260 

DESIGNER 

:  Labros  Karatasios 

DATE  :  4/30/1987 

INVOKED  BY  MODULE  : 

1200 


INVOKES  MODULES 


INPUTS  : 

ASSIGNMS 


OUTPUTS  : 

Printed  list  of  assign¬ 
ments 


PROCESS  :  See  Flowchart  in  Figure  D.3.16.a 


Figure  D.3.16  The  IPO  chart  of  program  PR_ASIGN 


PR-ASIGN 


Figure  D 


3.16a 


The  flowchart  of  program  PR-ASIGN 
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3 


SYSTEM  :  PERSONNEL  MANAGEMENT 

MODULE  NAME  :  ENL_SLDS 

MODULE  No  :  1300 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


Figure  D.3.17  The  IPO  chart  of  program  ENL_SLDS 
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1300 


Figure  D„3.17.a  The  flowchart  of  program  ENL-SLD5 


1 A  5 


SYSTEM  :  PERSONNEL  MANAGEMENT 

MODOLE  NAME  :  GET_ENL 

MODULE  No  :  1310 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


INVOKED  BY  MODULE  : 

INVOKES  MODULES  : 

1300 

INPUTS  : 

OUTPUTS  : 

Manual  ENLISTED  file 

ENLISTED 

PROCESS  :  See  Flowchart  in  Figure  D.3.1B.a 


Figure  D.3.18  The  IPO  chart  of  program  GET_ENL 
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1310 


(get-enl) 

'display 
'PURPOSE  of/ 
/PROGRAM 

;  =3= 

Ask  user  to 
'confirm  that 
'he  wants  to 
/■run  the  program/ 


1 


DISPLAY 
M_I D_NUMBER 
'and  ask  user 
'to  confirm  it/ 


1 

GET  ANSWER 

GET  ANSWER 


N 


N 


OPEN  file 
ENLISTED 


DELETE  all 
records  from 
ENLISTED 


APPEND 
a  record  to 
ENLISTED 

ENLISTED. ID  NUMBER^ 
M_I D_NUMBER 

DISPLAY: 
’"Enter  the, 
'soldier  ID 


GET 

ID  NUMBER 


'DISPLAY 
'the  fields/ 
/o  f  record 


Get  f le 1 ds : 

F_NAME,  M_I N I T I AL  , 
L_NAME ,  DATE_ENL, 
SERV_DUR . . . 

. . . PRF  UNI T3 


(  END  ) 


Figure  D.3.1Ba  The  flowchart  of  program  GET-ENL 
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SYSTEM  :  PERSONNEL  MANAGEMENT 

MODULE  NAME  :  ADD_SLD 

MODULE  No  :  1320 

DESIGNER  :  Labros  Karatasios 


DATE  :  4/30/1987 


INVOKED  BY  MODULE  : 

INVOKES  MODULES  : 

1300 

INPUTS  : 

ENLISTED 


OUTPUTS  : 

SLD_ADDR , 
SLD_TRAN , 

SLD_SERV , 
SLD_PREF 

PROCESS  :  See  Flowchart  in  Figure  D.3.19.a 


Figure  D.3.19  The  IPO  chart  of  program  ADD_SLD 
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® 


1320 

(addhsld) 

[OPEN  files: 
ENLISTED, 
SLD_ADDR, 
SLD_SERV , 
SLD_PREF , 
SLD  TRANSF 


GET  next 
record  in 
ENLISTED 


1 


SLD_ADDR . I D_NUMBER= 
SLD_ADDR.F_NAME 
SLD_ADDR  .  M_I  N I T  I  AL  = 
SLD_ADDR.L_NAME 
SLD_ADDR. STREET 
SLD_ADDR .CITY 
SLD_ADDR. STATE 
SLD_ADDR.ZIP 
SLD  ADDR. PHONE 


M_I D_NUMBER 
ENL  I  STED  .  F_NAIV1E 
ENLISTED. M_INITIAL 
ENL I STED . L_NAME 
ENLISTED. STREET 
ENLISTED. CITY 
ENLISTED. STATE 
ENL I STED .ZIP 
ENL I STED. PHONE 


Look  up 
|M_ID_NUMBER 
in  SLD  SERV 


I M _ I  D_NUrvlBER 

ENLISTED. 
ID  NUMBER 


Look  up 

I M _ I D_NUMBER 

in  SLD  ADDR 


APPEND  a  record 
to  SLD  SERV 


DISPLAY/ 
ERROR 
MESSAGE 


SLD_SERV, 
SLD_SERV , 
SLD_SERV , 
SLD_SERV, 
SLD_SERV, 
SLD_SERV , 
SLD_SERV, 
SLD_SERV , 
SLD_SERV , 
SERV  DUR 


I D_NUMBER  =M_I D_NUMBER 
DATE_ENL  =ENL I STED . DATE_ENL 
SERV_DUR  =ENL I STED . SERV  DUR 
CLASS  =ENL I STED. CLASS 

SPECIALTY  ="11111111" 

END_TRA I N  =False 
UNIT  ="1111111" 

DATE_ASIGN=01/01/01 
DATE_4  =DATE_ENL  + 

-  4  months 


APPEND 

a  record  to| 
SLD  ADDR 


& 


DISPLAY, 
ERROR 
MESSAGE 


Figure  D.3.19a  The  flowchart  of  program  ADD-SLD  (part  1  of  2) 
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Figure  D.3.19a  The  flowchart  of  program  ADD-SLD  (part  2  of  2) 
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SYSTEM  :  PERSONNEL  MANAGEMENT 

MODULE  NAME  :  TRAINING 

MODULE  No  :  1400 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


INVOKED  BY  MODULE  : 

1000 


INVOKES  MODULES  : 

1410,  1420 


INPUTS  : 

ENLISTED,  SLD_SERV, 
UNIT_.ORG ,  SPECS, 
TRAINEES,  TRAIN_REQ 


OUTPUTS  : 

TRAIN_REQ ,  Printed  list 
with  training  needs 


PROCESS  :  See  Flowchart  in  Figure  D.3.20.a 


Figure  D.3.20 


The  IPO  chart  of  program  TRAINING 


1400 
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SYSTEM  :  PERSONNEL  MANAGEMENT 

MODULE  NAME  :  TRN_NEED 

MODULE  No  :  1410 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


INVOKED  BY  MODULE  : 

INVOKES  MODULES  : 

1400 

INPUTS  : 

ENLISTED. 

SLD  SERV. 

UNIT  ORG. 

SPECS. 

TRAINEES 

OUTPUTS  : 

TRAIN_REQ 


PROCESS  :  See  Flowchart  in  Figure  D.3.21.a 


Figure  D.3.21  The  IPO  chart  of  program  TRN_NEED 
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1410 


(trn-need) 

OPEN  files 
ENLISTED, 
TRAINEES , 
SLD_SERV, 
UN  I T_ORG , 
SPECS, 
TRAIN  RQ 


INITIALIZE  Vars: 

TOTAL 

REQ=0 , 

TOTAL 

C0MP=0 , 

TOTAL 

RET=0 , 

TOTAL 

TR  =  0 , 

REGNO 

,  C0M=0 , 

TR=0,  RET=0 ,  X=0 

TOT  AL_COMP  = 
TOTAL  _COMP  + 

UNIT  ORG. COMPLEMENT 


CLOSE 

FILES 

*  HEZ 

C  END  ) 


Figure  D.3.21a  The  flowchart  of  prnnr^  TRN-NFED  In art  i  of  2) 
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Figure  D.3.21a  The  flowchart  of  program  TRN-NEED  (part  2  of  2) 
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Figure  D.3.22  The  IPO  chart  of  program  PR_TRAIN 
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PROCESS  :  See  Flowchart  in  Figure  D.3.23.a 


Figure  D.3.23  The  IPO  chart  of  program  STC_REPS 
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1500 


Figure  D.3.23.a  The  flowchart  of  program  STC-REPS 
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SYSTEM  :  PERSONNEL  MANAGEMENT 

.MODULE  NAME  :  COMP_TRN 

MODULE  No  :  1510 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


INVOKED  BY  MODULE  : 

INVOKES  MODULES  : 

1500 

1511,  1512 

INPUTS  : 

OUTPUTS  : 

Manual  list  of  trained 

COMPL  TR,  SLD  SERV 

soldiers,  C0MPL_TR 

PROCESS  :  See  Flowchart  in  Figure  D.3.24.a 


Figure  D.3.24  The  IPO  chart  of  program  COMP_TRN 


16  0 


1510 


Figure  D.3.24.a  The  flowchart  of  program  COMP-TRN 
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SYSTEM  :  PERSONNEL  MANAGEMENT 

MODOLE  NAME  :  GET_TRND 

MODULE  No  :  1511 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


INVOKED  BY  MODOLE  : 

INVOKES  MODULES  : 

1510 

INPUTS  : 

OUTPUTS  : 

Manual  list  of  trained 

COMPL  TR 

soldiers 

PROCESS  :  See  Flowchart  in  Figure  D.3.25.a 


Figure  D.3.25  The  IPO  chart  of  program  GET_TRND 
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Figure  D.3.25a  The  flowchart  of  program  GET-TRND 
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SYSTEM  :  PERSONNEL  MANAGEMENT 

MODULE  NAME  :  UPSLDTRN 

MODULE  No  :  1512 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


INVOKED  BY  MODULE  : 

INVOKES  MODULES  : 

1510 

INPUTS  : 

OUTPUTS  : 

COMPL_TF 

SLD_SERV 

PROCESS  :  See  Flowchart  in  Figure  D.3.26.a 


Figure  D . 3 . 26  The  IPO  chart  of  program  UPSLDTRN 
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1512 


(  EN 


The  flowchart  of  program  UPSLDTRN 


l(ir) 


lqurp  D.3.2£>a 


SYSTEM  :  PERSONNEL  MANAGEMENT 

MODULE  NAME  :  SP_TRNEE 

MODULE  No  :  1520 

DESIGNER  :  Labros  Karatasios  DATE  :  4/30/1987 


INVOKED  BY  MODULE  : 

INVOKES  MODULES  : 

1500 

INPUTS  : 

OUTPUTS  : 

Manual  list  of  trainees 

TRAINEES 

PROCESS  :  See  Flowchart  in  Figure  D.3.27.a 


Figure  D.3.27  The  IPO  chart  of  program  SP_TRNEE 
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1520 


Figure*  D. 3.27a  T  tie  flowchart  of  program  SP-TRNFF 


If.7 


APPENDIX  E 


PROGRAM-LISTINGS 


Section  E . 1 


************************************************************** 
*  * 

*  PERS-MGT  :  Main  control  program.  It  displays  a  menu  * 

*  screen  and  depending  on  the  user's  choice  * 

*  5/12/87  it.  gives  control  to  one  of  five  processes  * 

*  * 


Cl. EAR  &&  Clear  the  screen 

*  Initialize  basic  dBASE  III  Plus  functions 
CLEAR  ALL 

SET  TALK  OFF 
SET  BELL  OFF 

STORE  "  "  TO  CHOICE  &&  Initialize  variable  CHOICE 

*  Main  loop 
DO  WHILE  .T. 


* 

Display 

■  Main 

Menu 

& 

2 , 27 

SAY 

'PERSONNEL  MANAGEMENT  SYSTEM 

& 

3 , 38 

SAY 

'MENU" 

& 

6 , 20 

SAY 

'  1  . 

Units  Reports" 

<s> 

8 , 20 

SAY 

'2  . 

Assignments" 

@ 

10,20 

SAY 

'3  . 

New  Enlisted  Soldiers" 

& 

12,20 

SAY 

'4  . 

Training  needs" 

@  14,20  SAY  "5.  STC  Reports" 

@  16,20  SAY  "6.  Exit  Program" 

<s)  20,20  SAY  "Your  selection,  please  "  GET  CHOICE 


*  Execute  selected  process 
DO  CASE 


CASE  CHOICE  =  “1" 
DO  UNIT-REP 
CASE  CHOICE  =  "2“ 
DO  ASSIGNMT 
CASE  CHOICE  =  " 3 " 
DO  ENL-SLDS 
CASE  CHOICE  =  " 4 " 
DO  TRAINING 
CASE  CHOICE  =  "5" 
DO  STC-REPS 
CASE  CHOICE  =  "6" 
CI,EAR  ADD 
CLEAR 
RETURN 

ENDCASE 

ENDDO 


&&  Process  Units  Reports 

&&  Process  Soldiers  Assignments 

&&  Process  New  Enlisted  Soldiers 

&&  Estimate  Training  Needs 

&&  Process  STC  ReporLo 

&&  Exit  program 


Section  K.2  The_l  is  ting.j2f_Er2grflm.  EMlr^SLRS 


**4  4  *4.  +  ***  *  4-  **44****  +  **  +  *****  ****♦********♦*****************  + 


4 

4  KNL-SLDS  :  Program  to  enter  the  report  for  new  enlisted  4 
*  soldiers  into  the  system  and  to  update  the  * 

4  D/12/87  soldier  files.  * 

+  4- 


4  4444  44444444444444444  44  4  4444444444  4  44444444*************'  ***4.4. 


Cl, EAR 


&&  Clear  the  screen 


STORE  "  "  TO  EC 


Do  WHILE  .  T 

<s> 

2 , 24 

SAY 

3 , 38 

SAY 

<9> 

6 , 20 

SAY 

" ENIjI STED  SOLDIERS  PROCESSING" 
“MENU" 

"1.  Input  new  enlisted  data" 
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*•  * 


******* 


@ 

8,20 

SAY 

"2. 

Process  new 

data" 

@ 

10.20 

SAY 

"3  . 

Return  to  main  menu’ 

@ 

14,20 

SAY 

"Your 

selection , 

please" 

GET  EC 
READ 
DO  CASE 

CASE  EC  =  "l" 

DO  GET-ENL 
CASE  EC  =  "2" 

DO  ADD-SLD 
CASE  EC  =  "3" 

CLEAR  ALL 
CLEAR 
RETURN 
OTHERWISE 

*  Display  error  message 
CLEAR 

@  15,15  SAY  "Your  selection  must  be  1 ,  2  or  3 

CLEAR  ALL 

RETURN 

ENDCASE 

ENDDO 


Section  K.3 


********* **************************************************** 

* 

GKT-ENL  :  This  program  creates  the  ENLISTED  file  and  * 

updates  it  interactively  with  the  data  from  * 

5/12/87  the  EC  report.  * 

************************************************************* 

CLEAR 

CLEAR  ALL 
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SKT  TALK  OKK 
SKT  HKLL  oKK 

*  lit*  fine  what  the  program  does 

(«•  4  ,  £>  SAY  "This  program  a  1  lows  you  to  put,  new  aoldierts  into 
<a>  b ,  h  LAY  "the  eye  tern.  Note:  This  program  also  deletes  the 
(s>  (i ,  !>  LAY  “last  group  of  soldiers  that  were  put  in  the  system 
STORK  . TO  0 

(s>  1  (I ,  {)  SiAY  "Type  Y  to  proceed,  anything  else  to  abort." 

(IKT  C  VI  (’TURK  "!" 

KKAD 
OLKA  it 

I  K  0  «'  ,  "Y" 

RKTIIRN 
Kill*  I  I1' 

RUN  UKL  KNLISTKU.  UHK 
RUN  OOf'Y  TK.HHK  KNLISTKU  DBK 
US. K  KNLIS.TKU 
UO  WII  I  LK  .  T 
OLKAR 

(•i*  ,  h  S.AY  "Kntcr  0  t.o  exit." 

STORK  Sf'AOK(V)  TO  MIL  NUMHKR 
<•>  4  ,  h  S.AY  "Kntcr  II)  number 
OKT  MID  NUMHKR 
RKAi) 

UO  OAS.K 

CASK  VAL(MII)  NUMHKR)  -  U 
RKTIIRN 

OAS.K  VAI.(MII)  NUMHKR)  <  1000000 

(°)  7  ,  h  S.AY  "Invalid  II)  number" 

IK)  WHILK  VALIMIU  NUMHKR)  <  100000(1 
STORK  SRAOK(Y)  TO  MIU  NUMHKR 


I  /I 


STORE  SPACE ( 36 )  TO  CL 
@  4,5  SAY  "Enter  ID  number" 

GET  MID_NUMBER 
READ 

IE  VAL( MID_NUMBER )  =  0 
RETURN 
ENDIF 
ENDDO 

ENDCASE 

STORE  "  "  TO  CONF 

@  6,5  SAY  "Please  confirm  the  above  number  (Y  to  confirm)" 
GET  CONE  PICTURE  " ! " 

READ 

IF  CONF  <>  "Y" 

LOOP 

ENDIF 

STORE  SPACE ( 20 )  TO  MCITY ,  ML^NAME 

STORE  SPACE (15)  TO  MF_NAME ,  MSTREET ,  MSTATE 

STORE  SPACE (14)  TO  MPHONE 

STORE  SPACE (  7  )  TO  MPRF_UNIT1  ,  MPRF._UNJT2,  MPRF_UNIT3 
STORE  SPACE  f  5 )  TO  MZIP 
STORE  SPACE! 3)  TO  MCLASS 

STORE  SPACE! 1)  TO  MM_INITIAL ,  MMARIT_STAT ,  MFI NAN_  STAT 

STORE  "  "  TO  MFAM_SUPP ,  MSPEC_REAS 

STORE  CTOD( "  /  /  " )  TO  MDATE_ENL 

STORE  0  TO  MSERV^DUR ,  MNUM_CH I LD ,  MBROTH_SERV 

CLEAR 

@  1,24  SAY  "Entering  new  soldier  into  system" 

@  2,34  SAY  "ID  number : "+MID_NUMBER 

@4,5  SAY  "First  Name  "  GET  MF_.  NAME  PICTURE  "a" 

@  4,32  SAY  "M  Initial  "  GET  MM  INITIAL  PICTURE  "!" 
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@4,47  SAY  "Last  Name  "  GET  ML.NAME  PICTURE  "a" 

@6,5  SAY  "Street  "  GET  MSTREET  PICTURE  "a" 

@6,30  SAY  "City  "  GET  MCITY  PICTURE  "a" 

@8,5  SAY  "State  "  GET  MSTATE  PICTURE  "a" 

@8,28  SAY  "ZIP  "  GET  MZIP  PICTURE  "a" 

@8,39  SAY  "Phone  "  GET  MPHONE 

@  10,5  SAY  "Date  entered  Service  ”  GET  MDATE_ENL 
@  10,37  SAY  "Number  of  months  of  service  " 

GET  MSERV_DUR  PICTURE  “99" 

@  10,69  SAY  "Class  "  GET  MCLASS  PICTURE  "99!" 

@  12,5  SAY  "Marital  status:  (D)ivorced,  (M)arried, 

"(S) ingle,  (W)idowed  "  GET  MMARIT_STAT  PICTURE  "! 
@14,5  SAY  "Number  of  children  "  GET  MNUM_CHILD  PICTURE  "9 
@  14,30  SAY  "Financial  status:  (G)ood,  (M)edium,  (B)ad 
GET  MFINAN_STAT  PICTURE  "!" 

@  16,5  SAY  "Family  Supporter  (T/F) 

GET  MF AM_SUPP  PICTURE  " ! " 

@  16,30  SAY  "Number  of  brothers  in  service 
GET  MBROTH_SERV  PICTURE  "9" 


@ 

18,5 

SAY  "Priority  for  transfer 

(T/F)  " 

GET  MSPEC 

_  REAS 

PICTURE  "  ! 

@ 

20 , 5 

SAY  "List 

unit 

preferences 

#1  :  " 

GET  MPRF_ 

UNIT1 

PICTURE  "a 

•• 

@ 

20 , 39 

SAY  " #  2 : 

"  GET 

MPRF_UNIT2 

PICTURE  "a 

@ 

20 , 52 

SAY  "«3: 

"  GET 

MPRF_UNIT3 

PICTURE  "a 

READ 

IF 

MFAM_ 

_SUPP  -  'T 

STORE  .T.  TO  MFAM.SUPP 
ELSE 

STORE  . F.  TO  MFAM_  SUPP 
END  IF 
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IF  MSPEC_REAS  =  'T' 

STORE  .T.  TO  MSPEC_REAS 
ELSE 

STORE  .F.  TO  MSPEC_REAS 
ENDIF 

USE  ENLISTED 
APPEND  BLANK 

REPLACE  ID_NUMBER  WITH  MID_Nl)MBER,  F_NAME  WITH  MF_NAME 

REPLACE  L_NAME  WITH  ML_NAME ,  M_INITIAL  WITH  MM_INITIAL 

REPLACE  DATE_ENL  WITH  MDATE_ENL ,  CLASS  WITH  MCLASS 

REPLACE  SERV_DUR  WITH  MSERV_DUR ,  MARIT_STAT  WITH  MMARIT_STAT 

REPLACE  NUM_CHILD  WITH  MNUM_CHILD 

REPLACE  FINAN_STAT  WITH  MFINAN_STAT 

REPLACE  FAM_SUPP  WITH  MFAM_SUPP 

REPLACE  BROTH_SERV  WITH  MBROTH_SERV 

REPLACE  SPEC_REAS  WITH  MSPEC.REAS 

REPLACE  PRF_UNIT1  WITH  MPRF_UNIT1 

REPLACE  PRFJJNIT2  WITH  MPRF_UNIT2 

REPLACE  PRF_0NIT3  WITH  MPRF_UNIT3 

REPLACE  STREET  WITH  MSTREET,  CITY  WITH  MCITY 

REPLACE  STATE  WITH  MSTATE,  ZIP  WITH  MZIP,  PHONE  WITH  MPHONE 

STORE  "  "  TO  DA 

@  22,5  SAY  "Do  you  want  to  enter  another  soldier? 

GET  DA  PICTURE  " ! " 

READ 

IF  DA  =  "Y" 

LOOP 

ELSE 

RETURN 

ENDIF 

ENDDO 
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Section  E.4  The  listing  of  program  ADD-SLT) 


CLEAR 
CLEAR  ALL 
USE  ENLISTED 
GOTO  TOP 

DO  WHILE  .NOT.  EOF ( ) 

STORE  ID_NUMBER  TO  MID_NUMBER 
USE  SLD_ADDR  INDEX  SLAD 
SEEK  MID_NUMBER 
IF  FOUND (  ) 

@  4,5  SAY  "ID  Number  already  exists  in  address  file!!!" 
CLEAR  ALL 
CLEAR 
RETURN 
ENDIF 

USE  ENLISTED 

STORE  F_NAME  TO  MF_NAME 

STORE  M_.INITIAL  TO  MM_INITIAL 

STORE  L_NAME  TO  ML_NAME 

STORE  STREET  TO  MSTREET 

STORE  CITY  TO  MCITY 

STORE  STATE  TO  MSTATE 

STORE  ZIP  TO  MZ I P 

STORE  PHONE  TO  MPHONE 

USE  SLD_ADDR  INDEX  SLAD 

APPEND  BLANK 

REPLACE  F_NAME  WITH  MF_NAME ,  M_INITI AL  WITH  MM_INITIAL 
REPLACE  L_NAME  WITH  ML_NAME ,  STREET  WITH  MSTREET 
REPLACE  CITY  WITH  MCITY,  STATE  WITH  MSTATE,  ZIP  WITH  MZIP 
REPLACE  PHONE  WITH  MPHONE,  ID_NUMBER  WITH  MID_NUMBER 
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USE  SLD_SERV 
SEEK  Min_NUMBER 
IF  FOUND ( ) 

@  6,5  SAY  "ID  Number  already  exists  in  service  file!!!" 
CLEAR  ALL 
CLEAR 
RETURN 
ENDIF 

USE  ENLISTED 

STORE  DATE_ENL  TO  MDATE_ENL 
STORE  SERV_DUR  TO  MSERV_DUR 
STORE  CLASS  TO  MCLASS 
STORE  SERV_DUR  *  30  TO  MLS 
STORE  MLS  -  120  TO  MLE 
STORE  MDATE_ENL  +  MLE  TO  MDATE_4 
USE  SLD_SERV  INDEX  SLSE 
APPEND  BLANK 

REPLACE  ID_NUMBER  WITH  MID_NUMBER ,  DATE_ENL  WITH  MDATE_ENL 
REPLACE  SERV_DUR  WITH  MSERV_DUR ,  CLASS  WITH  MCLASS 
REPLACE  DATE_4  WITH  MDATE_4 ,  END_TRAIN  WITH  .  F. 

USE  SLD_PREF  INDEX  SLPR 
SEEK  MID_NUMBER 
IF  FOUNI)(  ) 

(a>  8,5  SAY  "  ID  Number  already  exists  in  preference  file" 
CLEAR  ALL 
CLEAR 
RETURN 
ENDIF 

USE  ENLISTED 


STORE 

PRF. 

JJNITl 

TO 

MPRF. 

JINITl 

STORE 

PRF_ 

J1NIT2 

TO 

MPRF_ 

J1NIT2 
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STORE  PRF_UNIT3  TO  MPRF_UNIT3 
USE  SLD_PREF  INDEX  SLPR 
APPEND  BLANK 

REPLACE  ID_NUMBER  WITH  MID_NUMBER ,  PRF_UNIT1  WITH  MPRF_UNIT1 
REPLACE  PRF_UNIT2  WITH  MPRF_UNIT2,  PRF_UNIT3  WITH  MPRF_UNIT3 
»  USE  SLD_TRAN  INDEX  SLTR 

SEEK  MID_NUMBER 
IF  FOUND ( ) 

@  10,5  SAY  "ID  Number  already  exists  in  transfer  file!!" 
CLEAR  ALL 
CLEAR 
RETURN 
EUDIF 

USE  ENLISTED 

STORE  MARIT_STAT  TO  MMARIT_STAT 
STORE  NUM.CHILD  TO  MNUM.CHILD 
STORE  FINAN..STAT  TO  MFINAN..STAT 
STORE  BROTH_SERV  TO  MBROTH_SERV 
STORE  FAM_SUPP  TO  MFAM_SUPP 
STORE  SPEC. REAS  TO  MSPEC_REAS 
USE  SI.D_TRAN  INDEX  SLTR 
APPEND  BLANK 

REPLACE  MARIT_STAT  WITH  MMARIT_STAT 

REPLACE  ID_NUMBER  WITH  MID_NUMBER ,  NUM_CHILD  WITH  MNl)M_CHILD 
REPLACE  F I NAN_STAT  WITH  MFINAN_STAT 
REPLACE  BROTH_SERV  WITH  MBROTH_SERV 

REPLACE  FAM_SUPP  WITH  MFAM_SUPP,  SPEC_REAS  WITH  MSPEC_REAS 
USE  ENLISTED 
IF  .NOT.  EOF ( ) 

SKIP 

ENDIF 


177 


LOOP 


ENDDO 

USE  ENLISTED 
DELETE  ALL 
PACK 

CLEAR  ALL 
RETURN 
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